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ABSTRACT 


Acquisition of weapon systems for the Department of Defense is governed by the 
regulation DoD 5000.2R, “Mandatory Procedures for Major Defense Acquisition 
Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition 
Programs.” During acquisition reform, this document was created as a simplified 
regulation to allow regulatory relief to acquisition project managers. It replaced two 
lengthy volumes providing requirements and guidance on acquisition procedures. The 
thesis analyzes the new regulation from a project process perspective. First, a 
requirements analysis is performed to identify project management requirements. Second, 
a functional analysis allocates these requirements to a timeline, creating a “Functional 
_ Architecture.” The Functional Architecture provides the basis for evaluation of the DoD 
5000.2R project management process. Finally, an evaluation is conducted from 
comparison with established soiumiucatons models and management studies. Results of 
these analyses reveal over 3000 tasks are required of acquisition programs. This large 
number of requirements indicates extreme oversight of acquisition programs continues 
within acquisition reform. Recommendations are made for reevaluation of DoD policy on 


acquisition management and rewrite of DoD 5000.2R. 
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I. INTRODUCTION 


A. PURPOSE 


This thesis analyzes the regulation Department of Defense (DoD) Regulation 
5000.2R "Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and 
Major Automated Information System (MAIS) nies Provan” This analysis 
leads to evaluation of this critical document’s effectiveness in regulating acquisition 


programs and executing DoD acquisition policy. 


B. BACKGROUND 


The United States Department of Defense (DoD) currently uses Project and 
Product Managers who are ill-prepared for the management of complex technical projects 
-- an unfortunate but correctable situation. | 

The United States enjoys anpaialeica military capability, primarily due to the 
intense screening and training performed for military personnel of all Services. 
Confidence in the military by US officials is well earned .. on the battlefield. However, 
specialty training for combat does not translate to leadership in acquisition. This has been 
proven when project and product managers are selected from combat units to manage 
technical system development and acquisition. 

Due to the complex, developmental and especially technical nature of DoD 


acquisitions, systems engineering is required for successful management (Gunther, 1995). 





While systems engineering processes are documented in industry standards, expertise is 
required to adapt these processes to defense acquisition programs. 

Research on practices within DoD acquisition has revealed a gap between 
acquisition managers’ actual “know-how” and the expertise required by their jobs 
(Thompson and Jones 1994, 141). While DoD-wide response to the Defense Acquisition 
Workforce Improvement Act (DAWIA) (Chapter 87 of Title 10, United ite Code) 1s 
improving the training provided to all acquisition personnel, the majority of managers are 
still limited in seguisitontourced education opportunities. Typically, the culmination of 
Project Management preparation is the Defense Systems Management College Project 
Managers Course. It is not viewed as adequate, given the responsibilities to be assumed 
by these managers (Fox and Field 1988). | 

In the past, DoD has attempted to provide aeguiction managers detailed policy 
and procedural guidance. To this end, the DoD Instruction 5000.2 and DoD 5000.2M 
Manuals of September 1987 were provided. These documents provided a ila 
process for the development of systems, including standardization of documents used for 
program management. However, the process defined in these large documents aid not 
lead to better managed systems. In fact, the seicunl of control placed on acquisition 
programs by these documents was determined to be “unwieldy and too complex," given 
the unique nature of each acquisition program (Kaminski, Coyle and Paige 1996). In 


1996, these two documents were replaced with a half-inch thick regulation DoD 5000.2R. 


In an accompanying memorandum, Kaminski, Coyle and Paige phrased the intent of this 








regulation, "By minimizing the volume of mandatory guidance, we can free managers to 


exercise sound judgement when structuring and executing defense acquisition programs." 


C. PROCEDURE 


The DoD 5000.2R will be analyzed for the level of constraint imposed on the 
_ Project Manager (PM) and for implications in its use as a communications tool for policy 
management. 

This research is conducted in two stages. The first stage involves equrements 
and functional analyses to quantify the number of constraints in DoD 5000.2R on project 
management. This is done using a systems engineering standard process from TEEE 
Standard 1220-1994. The results of the functional analysis is a Functional Database for 
DoD project management. In the second stage, the DoD 5000.2R and its Functional 
Database are then analyzed using a formal seanieabaaaias model and published 


management studies. 


D. | RESEARCH QUESTIONS 
1. Primary Question 


To what extent does the DoD 5000.2R constrain the project manager? 


2. Subsidiary Questions 


a) DoD 5000.2R Project Management Requirements 


What are the requirements included in the 5000.2R that affect defense 


acquisition project management? 





b) DoD 5000.2R Project Management Process 
What common functions are required to be performed by project 
management? 


What requirements must these functions meet? 


Cc) Quantitative Analysis of Findings 


What are the quantities and distribution of requirements among project 


management functions? 


d) Qualitative Analysis of Findings 
How effective is DoD 5000.2R as a communication tool? 


What implications for DoD acquisition policy can be obtained from this 


analysis? 


E. ORGANIZATION OF STUDY 


For a diagram of study organization see Figure 1. 

Chapter [I provides a requirements analysis for project management processes. A 
methodical extraction of constraints from DoD 5000.2R is performed and its results are 
considered in Chapter II. The result of this analysis is a Requirements Baseline presented 
in Appendix A. | 

Chapter Il analyzes the functional requirements for project management 
processes. This includes allocating performance requirements to required functions and 


identification of functional considerations such as timelines. The requirements allocated 


to specific life cycle functions constitute the Functional Database. 
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Figure 1. Study Flow (Source: Developed by Researcher) 
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Chapter IV analyzes DoD 5000.2R, its Requirements Baseline and its Functional 
Database. They are analyzed by quantitative and qualitative methods. Implications of this 
regulation’s effectiveness and implied DoD management philosophies are explored. 

Chapter V concludes the thesis study by summarizing the findings, answering the 


research questions, and providing recommendations for DoD action and further research. 


F. BENEFITS OF THE STUDY 


_ Benefits of this study are threefold. The first benefit is the identification of DoD 
project management tasks, requirements, and constraints as an amplification of that 
obtained through course work by the student. The second benefit is an understanding to 
the student and readers of DoD 5000.2R's true level of constraint and implications of this 
level. The third benefit is the requirements baseline (Appendix A) which provides 
background for further study of DoD project management tasks and acquisition policy. 

This thesis study also provides information that extends work of both the 
International Council of Systems Engineers (INCOSE), in the area of defense system 


engineering, and Project Management Institute (PMI), in the area of DoD project 


management. 











II. PROJECT MANAGEMENT REQUIREMENTS 


A. INTRODUCTION 


The DoD 5000.2R is used to define the process of acquisition project 
management. In this chapter the structure of DoD 5000.2R is discussed and the processes 
to extract specific requirements is described. The resulting requirements database is 


included in Appendix A. 


B. DOD 5000.2R 
1. Issuance 


The regulation DoD 5000.2R, "Mandatory Procedures for Major Defense 
Acquisition Programs and Major Automated Information Systems”, is authorized by the 
Secretary of Defense in er of Defense Directive DoDD 5000.1. It is coordinated — 
by the Director, Acquisition Program iniepanon and is released = the Under Secretary 
of Defense for Acquisition and elias, Change three of DoD 5000.2R, which was 
released in March 1998, was used for this research. 

The DoD 5000.2R was a replacement for several documents. This reduced the 
volume of detailed requirements. The initial DoD 5000.2R was introduced in 1996 as 
‘isis requirements for acquisition and empowering the program manager to 


independently take actions within the law and program charter. 








Ze Purpose 


There were five stated purposes for the DoD 5000.2R: 
a. to establish a simplified and flexible framework for Major Defense. 


Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) 


Programs, 
b. to delineate mandatory procedures for all acquisition programs. 
c. to establish a model for programs that are not considered MDAPs or 
MAIS. 
d. to disseminate statutory requirements for all acquisition programs, and 
e. to implement higher DoD directives for execution of defense 
acquisitions. 
3. Implementation 


Of particular note, DoD components e forbidden from supplementing this 
regulation with additional instruction (DoD 1998). This limitation makes the DoD 
5000.2R the key document in determining constraints for defense acquisition project 
management. Upon release of the DoD 5000.2R as a saith for a number of other 
acquisition regulations, it became a single point of reference for DoD acquisition 
programs. 


4. Construction 


The regulation is divided into six parts. 











a) Part 1. Acquisition Management Process 


This section defines the general model for managing acquisition programs. 
This model is presented for reference and is to be tailored based on individual program 


circumstances. 


b) Part 2. Program Definition 


The mandatory process required to establish operational requirements is 
documented in this section. This is called program definition and includes aspects of the 


requirements. 


Cc) Part 3. Program Structure 


The program structure section identifies elements to be used in structuring 
the program. The elements address what the program will achieve, how the program will 


be developed and evaluated, and what resources will be used. 


d) Part 4. Program Design 


This section mandates Integrated Product and Process Development and 
Systems Engineering as the basis for life cycle design of the program. The systems 
engineering portion is the largest of these and is detailed relative to other processes 


described in the DoD 5000.2R. 





e) Part 5. Program Assessments and Decision Reviews 


Milestone decisions and other assessments are delineated in this section. 
Additionally, the Integrated Product Team (IPT) structure above the project office is 


structured here. 


2) Part 6. Periodic Reporting 
Mandatory reports for both the project office and contractor are defined in 
this section. 

2. The DoD 5000.2R as Requirements Document 

The DoD 5000.2R is essentially a requirements source for the process of 
acquisition management. The regulation was reviewed as a requirements document prior 
to performing the analysis. 

Common problems encountered when describing requirements, such as those in 
this regulation, include confusion due to eonple conditional wanes. inconsistent use of 
terminology, and omission of essential information (Sommerville and Sawyer 1997, 141). 
Problems such as these lead to errors and omissions, which lead to differing 
interpretations. 

The DoD 5000.2R, while smaller than previous documents is still quite detailed. 
Change 3 to the document replaced a — of "will" statements into "shall" statements. 
This turns guidance into a requirement making the document more constraining than it 
was originally. Also a large portion of the requirements are nested in extremely long, 


complex sentences. This was the first indication that a structured requirements 
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documentation approach would be required in order to extract specific constraints from 


the nests. 


C. METHOD OF REQUIREMENTS ANALYSIS 
1. Introduction 


The method used for analysis of the DoD 5000.2R constraints was a tailored 
version of that found in the IEEE Standard 1220-1994 "Trial-Use Standard for 
Application and Management of the Systems Engineering Process.” Requirements 


Analysis of DoD 5000.2R was conducted to determine specific requirements for the DoD 


: Requirements ; Requirements 
DoD 5000.2R_ | Analysis Database 


Mandatory 
Procedures for 
MDAPs and MAIS 
Programs 





Figure 2. Requirements Analysis Context (Source: Developed by 
Researcher) | 


Acquisition process. As shown in Figure 2, a requirements analysis was used to screen 
this regulation and assemble a requirements database which lists specific requirements. 
This database is Appendix A to this thesis. Due to the fact that this is an analysis of one 
source document, several of the JEEE P1220 tasks were combined. Tailoring of this 


process is presented in Table 1 and the resulting flow in Figure 3. 
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Table 1. Tailoring of Requirements Analysis (Source: Developed by Researcher) 


IEEE Task | Order Used / Not Used 


6.1.1 Define Customer Expectations (embedded in other DoD 
5000.2R rqmts) 


} 
| 5000.2R rqmts) 
unpredictable) 


Define Measures of Effectiveness 
Define System Boundaries 


6.1.7 Define Interfaces (embedded in other DoD 
5000.2R rqmts) 


a 
unpredictable) 
oe 
A. 4 
ne N 
wile 
















4 
8 
6.1.11 Define Performance Requirements , 
6.1.12 Define Modes of Operations 
oye ee, Define Technical Performance Measures 
Define Physical Characteristics ot Applicable _ 
6.1.15 Define Human Factors | 6 
16 


Establish Requirements Baseline 





Zs Analysis Process 


A structured process for documenting extracted constraints was defined following 
best practices for requirements capture (Sommerville and Sawyer 1997, 141). First a 
standard template was defined for capturing these requirements. The language used to 
describe the requirements was structured in simple, concise sentences. Consistency was 
maintained by continual indexing of terms used for all elements of the simple sentences. 


Additionally, all explicit and implied requirements were identified. 
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6.1.6 Define 
System 
Boundaries 


6.1.9 Define 
Life Cycle 
Concepts 


6.1.10 Define 6.1.11 Define . 6.1.2 
Functional Performance Define 
Reqmts Reqmts Constraints 


6.1.5 Define 6.1.13 
Measures of ‘| Define Technical 
Effectiveness alls Perf Measures 


6.1.12 
Define Modes of 
Operations 


6.1.15 
Define Human 
Factors 


6.1.16 
Establish 
Reqmts 





Figure 3. Tailored Requirements Analysis Steps (Source: Developed 
by Researcher) 7 


a) Step I. Define System Boundaries 

Requirements extracted during this analysis were for the project manager, 
Milestone Decision Authority, and the system’s user as defined in the DoD 5000.2R. 

The purpose of this analysis of the system boundaries was to define the 
constraints on the project manager. The DoD 5000.2R includes requirements for a 


number of acquisition positions such as Project Manager, Milestone Decision Authority, 
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and Component Acquisition Executive. For this reason system boundaries were set first 
and used to limit the number of requirements extracted.. The primary project level 
interfaces defined in DoD 5000.2R are those between the project office and the Milestone 
Decision Authority, and between the project office and the user of equipment to be 
acquired. By including requirements for these primary interfaces to the project manager, a 


number of implied requirements were derived for the PM. 


b) Step 2. Define Life Cycle Process Concepts 

Part 4 of the DoD 5000.2R defines life cycle functions wad as a project 
process. While the regulation lists nine functions, standard practice is to use eight of these - 
combining "Test and Evaluation" with "Verification" (IEEE, 1995). Standard practice 
was used in this analysis. These functions are Development, Verification/ Validation 
(sometimes referred to as “Testing” Producten: Fielding, Training, Support, Operations, 
and Disposal. A more detailed development process was defined in the DoD 5000.2R in . 
parts 1 and 6 which describe the general model and major reviews. This process is to be 
used as a starting point for tailoring of any acquisition program. These details along with 
the life cycle functions were integrated to provide a concept for the life cycle process 
required under the DoD 5000.2R. Table 2’ shows the life cycle function and development 
phase combinations used to categorize the requirements. Note that development phases 
are only required for the development life cycle function. Other life cycle functions are 


not broken down further. 
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Table 2. Life Cycle Functions and Phases for Requirements (Source: Developed by 


Researcher) 







Phase J (Program Definition/ Risk Reduction) 





These life. cycle functions with detailed phases for development were 


identified in this analysis as the life cycle process concept required by DoD 5000.2R. 
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Cc) Step 3. Define Constraints, Functional Requirements, and 
Performance Requirements 


A review of each paragraph in the DoD 5000.2R was conducted for 
applicability, then individual functions required or implied were extracted to the template. 

Using a plain language template of requirements, three steps of the IEEE 
P1220 were combined. This template consisted of a noun, verb, object, and modifiers to 
be extracted for each requirement. The noun identified whether the requirement was for 
the PM or interfacing organization. The verb indicated the function required of the 
organization. The object allowed categorization of subsystems and system elements 
influenced by the functions, while the modifiers provided constraints for the functions. 

Each requirement ee two items of additional information: the phase 
in the life cycle concept where meeting the requirement was identified, and the 


mechanism, if any, that was required for documentation/ execution of the requirement. 


d) Step 4. Define Measures of Effectiveness and Technical 
Performane Measures 


No measures of effectiveness or technical performance measures were 
identified within DoD 5000.2R. 

Once the requirements list was established, none of the constraints was 
adequate for a generic measure of effectiveness or techincal performance measure. These 
were left by the regulation to be project: specific. While there were requirements for 


reporting given specific levels of cost and schedule overruns, these were inadequate for 
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MOE or TPM use without understanding funding, timescale, or performance impact of 


the overrun. 


e) Step 5. Define Modes of Operation 

The modes of operation are the same as life cycle phases determined in 
Step 2. The requirements list was reviewed for modes associated with project 
management. These were clearly distinguished in DoD 5000.2R Part 1 by phase of 
development. These modes were verified for phases from pre-Milestone 0 selon: 


through disposal by documented DoD concepts (Gunther, 1995). 


Np Step 6. Define Human Factors 


The DoD 5000.2R requirements were reviewed to identity any potential 
human factors constraints. The DoD 5000.2R does not explicitly address human factors 
_ for either physical or mental requirements of personnel involved in acquisition. 

While no human factors constraints were found, the number of 
requirements is a potential human factors issue. Management studies indicate that as 
personnel become more competent at their work, less direction is required. Additionally 
these ee have shown that high level managers, PMs in this case, must have high 
, technical competency in tasks that their organizations perform (Lazarus 1980). If DoD 
policy selene agree with these study results, the extremely large number of requirements 
in DoD 5000.2R imply that they consider their project managers to be incompetent at 
technical project management. Other aie: ee the more uncertainty in a job the 


less direction should be given by higher levels to allow utilizing expertise of personnel 
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performing the job (Cummings and Huse 1996, 285). Acquisition programs typically 
contain a great deal of uncertainty in funding, schedule, and performance. The large 
number of requirements, and the wide variety of programs covered by this document, may 
imply that DoD policy makers are attempting to control them from the top using project 
personnel that are incompetent. This does not follow current sound management 


practices. 


g) Step 7. Establish Requirements Baseline 


A requirements baseline was established in list form that included 
constraints obtained during the previous steps. The list was modified to a flat database 
form of the list and terminology was reviewed again to ensure internal consistency se 
sorting and reporting results. 

Utilizing a database form for the list allowed a single document support 
the three views required by IEEE P1220. These views are operational, functional and 
physical. 

The operational view for this application allows determination of 
requirements for PM, Milestone Decision Authority or “User.” It also allows 
requirements associated with specific reports to be identified. A functional view of DoD 
5000.2R requirements provides a list of requirements for each type of function or life 
cycle function. While there are no physical requirements in the DoD 5000.2R to respond 


to a physical view, there are design constraints that influence physical solutions and 
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development constraints. A sorting based on life cycle function provides this view for the 


development function. 


3. Tools 


A combination of Microsoft Word and Excel was used to capture the quotations 
from a digital copy of DoD 5000.2R. Specific language was copied from the regulation to 
Excel. There it was decomposed into specific requirements meeting the defined template. 
Once a database form was achieved Excel was used to sort the database. 


4. Categories of Requirements Database Fields 


The final categories used for the requirements database are described in Table 3. 


Table 3. Requirements Database Fields (Source: Developed by Researcher) 


identification. 
was found. A 
found. 
requirement. 
Verb 
Object 







Noun Which organization was to fulfill the requirement (limited 
to PM, MDA, User) 


Verb sssssis The function required to be performed. 
‘Object The object on which the function was performed 


Using The specific report, plan, or tool to be used in performing 
this requirement. 
Performance requirements if any for this function. 


When Which phase and life cycle function was associated with 
7 this requirement. 
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D. RESULTS OF REQUIREMENTS ANALYSIS | 


The requirements analysis identified 437 statements in the DoD 5000.2R that 
required action from either the PM, MDA, User or some spun aan on Based on these. 
statements, 862 specific requirements were derived. While many statements contained 
only one requirement, many others were complex. For example, one very complex 
statement created 18 individual requirements (see uiahenen aamber 673 — 690 in 
Appendix A). 

Of the 862 requirements, 770 were for accomplishment - the PM, 29 were for 
the MDA, 51 were for both the PM and MDA, 11 were to be accomplished by the User, 
and one required action from all three, PM, MDA, and User. 

The results of this analysis are that there are 322 specific requirements for the PM 
to meet during the acquisition. In the following section these requirements will be 
allocated to the life cycle concept to saleian the effects of iterative requirements on 


this total number. 


E. CHAPTER SUMMARY 


Results (Appendix A) show a very large number, 822, of specific requirements for 
the PM to meet during the acquisition. The following sections will determine effects of 


iterative development on this number. 
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Ill. PROJECT MANAGEMENT FUNCTIONS 


A. INTRODUCTION 


This section describes the functional analysis conducted on the DoD 5000.2R 
Chapter II project management requirements. This functional analysis was conducted to 


fully identify the functions required to be performed or tailored. The results of this 
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Figure 4. Functional Analysis Context (Source: Developed by Researcher) 


analysis provide a list of functions, the Functional Database in Figure 4, along with those 
requirements these functions must meet. This listing follows the systems engineering 


process (IEEE, 1995) as a "functional architecture.” 


2) 








B. METHOD OF FUNCTIONAL ANALYSIS 
1. Introduction 


This analysis was conducted using a process described in IEEE P1220 (IEEE, 
1995). The analysis process was tailored to one source for requirements. The tailoring is 


presented in Table 4. 


Table 4. Tailoring of Functional Analysis (Source: Developed by Researcher) 


Define Functional Failure Modes & 


ry 


Effects 


Define Hazard Monitoring Functions 


Establish Functional Database 





All portions of Steps 1 and 2 were conducted in conjunction with the requirements 
analysis described in Section II of this thesis.. The flow of tasks performed on each DoD 
5000.2R statement was from requirements analysis to functional analysis. This flow was 


organized after realization of the magnitude of requirements in this one document. 
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2. The Analysis 




























6.3.1.2 Define 
Functional 
Interfaces 







6.3.1.1 
Define 
Subfunctions 






6.3.1.3 Allocate 
Performance 
Requirements 


6.3:4 Define 
Functional 
Timelines 


6.3.3 Define 
Subfunction 
States & Modes 





6.3.5 Define 
Data & Control 
Flows 


6.3.8 Establish 
Functional 
Database 






Figure 5. Tailored Functional Analysis Steps (Source: 
Developed by Researcher) 


a) Step 1. Define Subfunctions and Functional Interfaces 

After a requirement statement was documented and analyzed for 
performance or functional content, it was then decomposed. This decomposition 
consisted of determining if the statement required additional, undocumented subfunctions 
to take place. If so, the detailed requirements were decomposed into additional functions. 


For instance, requirements to "report" the results of analysis created an implied 
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requirement to first conduct an analysis. This lead to at least two functions for one 
explicit requirement. This type of requirement was common in DoD 5000.2R. 

This decomposition establishes a number of functional interfaces. Where 
an interface was not clear between two subfunctions, an additional interfacing function 
was identified. For instance, if the analysis report was extensive and implied a great deal 
of effort to write, then documenting the analysis is an additional function. Interfacing 


functions were not ordinarily needed, due to the detailed nature of the DoD 5000.2R 


requirements. 


b) Step 2. Allocate Performance Requirements 


Allocating performance requirements for this analysis was more a case of 
inheritance than allocation. The nature of performance requirements in this document 
were schedule-oriented, requiring that a series of subfunctions be completed prior to a 
certain milestone or during a certain phase. Allocation of time among these subfunctions 
is greatly dependent on program-specific elements. Therefore, any performance 


requirements were inherited by all affected subfunctions. 


c) Step 3. Define Functional Timelines 


Timelines for acquisition project management functions were developed in 
three ime scales. These include life cycle process, development process, and systems 
engineering processes. 

DoD 5000.2R provides sie distinction between the functions performed 


by the project office during the seven life cycle phases (development, test and evaluation, 
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production, fielding, training, operations, support, and disposal). There were requirements 
allocated to all phases with the development phase having by far the most requirements. - 

Timelines for development phases were defined in the development model 
presented in Part I of DoD 5000.2R. This model is subdivided by formal “Milestone 
Decisions," which provide authority to continue into the next development phase. The 
phases consist of pre-milestone 0 (Determining Mission Needs iad Identifying 
Deficiencies), Phase 0 (Concept Exploration), Phase I (Program Definition and Risk 
Reduction), and Phase I (Engineering and Manufacturing Development). — 

Further, DoD 5000.2R requires a systems engineering process be used in 
project management. This process consists of five, separate, major tasks: requirements 
analysis, functional analysis, synthesis, analysis, and control (DoD 1998; IEEE 1995). 
These tasks are performed during each phase of sevclopment at progressively more 


detailed levels (DoD 1998). 


d) Step 4. Define Subfunction States and Modes 


For the purposes of this analysis, a state is defined as the behavior of a 
subfunction at a particular point in time. A mode is defined as an operating condition in 
which there are typically many states (IEEE, 1995). 

Modes for an acquisition project were clearly defined along life cycle and 
development phase lines (Step 3, above): While many functions are repeated for each 


phase of development, the level of detail considered in each phase is very different. Thus, 


2D 


functions were assigned to the life cycle process and then, if part of the development 
process, to the phase for which they were required. 

Functions from the database were further allocated within development 
phases to specific systems engineering tasks. This provided insight into the reasoning for 
using each function in that particular phase. Systems engineering tasks do not really 
present independent states, in that several tasks may be going on at once. These tasks are 


better considered, in this context, as submodes. 


e) Step 5. Define Data and Control Flows 


Data and control flows are embedded in the DoD 5000.2R requirements 
and were identified during establishment of modes down to the systems engineering task 
level. This step was conducted to ensure ie flows were identified, if required. 

The primary project level data and controls are established by DoD 
5000.2R through a series of four formal milestone decisions during development. These 
milestones utilize data from the systems engineering process and project control functions 
conducted during the previous phase to decide whether to continue into the next phase of 
development. Project control functions include capture of changes in the system, 
technical management (data, configuration, interfaces, risk and progress), life cycle 
performance tracking and updating of plans and estimates. This primary flow is presented 


in Figure 6. 
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Figure 6. Primary Project Level Data and Control Flow (Source: Developed by 
Researcher) | | — eo 





) | Step 6. Establish Functional Database 


A database was prepared to hold the information captured in both the 
requirements at functional analyses. This database allowed sioetien of each 
requirement to all portions of the life cycle of project management to which it applied. 
This capability was used extensively to capture the iterative nature of the acquisition 
development model. 


3. Tools 


The functional architecture was assembled in a relational database supporting all 
relevant information from DoD 5000.2R detailed requirements. The database was built in 


digital format using Microsoft ACCESS 98. The Excel spreadsheet containing the 
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requirements database was imported into ACCESS, and then modified to the final 


configuration. 


4. Adjustments to the Requirements Database 


The Functional Database was captured in a relational database. The Requirements 


Database was in spreadsheet form. The construction of a relational database from the 


Excel-based flat database required introducing a number of inter-related tables. These 


tables contain the information from the requirements database, in associated tables, plus 


the additional information gained from the functional analysis. The following Table 5 and 


Figure 7 describe this relational database. 


Table 5. ACCESS Functional Database Configuration (Source: Developed by 


Researcher) 


Table Name 
DoD 5000.2R 


Derived Requirements 


Reference 


No. of Records 
442 
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Figure 7. Transformation of Excel Requirements Database to ACCESS Functional Database 
(Source: Developed by Researcher) 





C. | FUNCTIONAL ANALYSIS RESULTS 


The six steps of the functional analysis established the connections between the 
functions and the timing. The total number of allocated functions was 3,040. 

Of the 3,040 required functions, 2,744 were to be performed by the PM, 61 by the 
MDA and 199 by both. The User is responsible for performing 32 of these functions and 
all three positions get four functions. 

The primary cause of increases in functions from the baseline to the allocated 
functional architecture is the establishment of a timeline. By assigning functions to 
timelines, the iterative nature of the required development becomes apparent. Many 
required functions were conducted "throughout the development" or "during each phase” 
(DoD 1998). Iteration in this case significantly multiplied the number of functions. Care 
was taken during development of this database to only assign required functions when 
they were consistent with work expected during phases of the acquisition process as 
described in DoD 5000.2R Part I. However, if a case could be made for conducting a 
function in a particular phase, it was so assigned. 

_ For iterative timelines, an issue encountered was the assignment of functions to 
time periods prior to "Milestone 0.” A systems engineering process is considered 
necessary by DoD semicon education sources during early consideration of mission 
needs prior to Milestone 0 (Gunther, 1995). These early functions are understood by the 
author to be conducted by an organization that is either a project within a research and 


development organization, a doctrine and requirements organization, or an existing 
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project office considering an new product. These early requirements were assumed to be 


included in the timelines associated with the functional architecture. 


D. DATABASE DEVELOPMENT 


The functional architecture was captured using a relational database. The strength 
of a relational database is the separation of unique information into separate files. This 
reduces the size of any one file and reduces the input work required to describe a set of 
data. Additionally, it clarifies classification of data and facilitates approaches to analysis. 
This database used tables to classify DoD 5000.2R requirements from two distinct 
perspectives, timeline and source. 


1. Timeline Perspective 


Three tables were developed to allow categorizing of requirements by timeline 
and allow for iteration of a large number of furictions (see Figure 7). 

The first of these tables named "Sort Titles" was developed to allow sorting of 
requirements by life cycle function (field: LC Function) and development phase (field: 
Phase) during which they are to be performed. A unique record number was assigned as a 
key field. 

The second table was developed to accept the requirements of DoD 5000.2R to 
iterate the systems engineering process. This table, named simply "SE," contains the five 
systems engineering functions (field: SE Function) and an "All" value. There is also an 


‘identifier (field: SE Code) for use as a reference. While containing only two fields, this 
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table was maintained as separate from other tables to allow future elaboration on systems 
engineering functions using additional fields. 

The third table, named "When", ties the other two into one or more time 
references for each requirement. The life cycle function and phase identifiers are used in 
conjunction with the systems engineering identifier to tag each requirement with the 
timings identified by DoD 5000.2R. Requirements are identified ™ their unique 
requirement number (field: Rqmt No). A unique identifier was also established for each 
record in this table (field: When No). 


Ze Source Perspective 


Two tables were used to establish DoD 5000.2R sources for each requirement (see | 
Figure 7). | 

The first, named "DoD 5000.2R", contains the original quotes and section 
identification for requirement statements taken from the regulation. This includes a 
section number (field: Section No), a combination of section number and title (field: 
Section Title) and the statement in regulation language (field: Quote). Additionally, a 
number was used to identify the order these statements were taken from the eoalion 
This number (field: Entry No) is unique for each statement. 

The second table, named "Reference", simply ties each requirement to the 
statement from which it was derived. This is done by tracking unique combinations of 


requirement number and entry number. 
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E. CHAPTER SUMMARY 


A functional analysis was conducted on the requirements obtained from DoD 
5000.2R. The results of the functional analysis are contained in a relational dipiabice and 
i called the "functional architecture” of these requirements. Of particular note is the 
timeline nature of this architecture. Requirements in the DoD 5000.2R to perform 
functions in an iterative nature multiply the number of original requirements to a very 


large number (2744) of Project Management functions. 
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IV. QUANTITATIVE AND QUALITATIVE ANALYSES 


A. INTRODUCTION 


Both quantitative and qualitative analyses were conducted to analyze DoD 
5000.2R and its level of control on DoD acquisition project management. The 
quantitative analysis described in this section identifies the requirements drivers leading 
to the large number of allocated functions. The qualitative analysis analyzes the drivers 


on DoD management, as executed through the DoD 5000.2R. 


B. QUANTITATIVE CHARACTERISTICS. 


A quantitative Pareto analysis of the Functional Database was conducted to. 
determine the causes of the large number of requirements (see Figure 8). A Pareto 
analysis contends that a minority of causes contain the majority of requirements. 


Pareto analysis identifies the vital few causes to guide further investigation. 


| Typically, the percentages reflect that the top 20% of categories by number of functions 


contain 80% of the total number. These "20/80" percentages were for the Pareto analysis 
results presented in this séction. The analysis consisted of "drilling down" until either a 
particular source for this large number of requirements could be located or the Pareto 


chart showed there were no drivers present. 
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Figure 8. Quantitative Analysis Context (Source: Developed by 
Researcher) 
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1. Life Cycle Requirements Breakdown 


The initial analysis was conducted at the top level, which covers the life cycle 
functions: Development, Test / Verification and Validation (VandV), Production, 
Fielding, Training, Support, Operations, and Disposal. An additional category for System 
Modification was added to accept a requirement not applicable to normal development. 
Each of these nine functions was examined for number of cede allocated in the 
Functional Database. 

Results ( 

Chart 1) show that 93% of the DoD 5000.2R allocated requirements applied to the 
development portion of the system's life cycle. These results compare with the next | 
highest function, Test/VandV, which accounts for only 2% of the total aunnber This 
shows Development to be the driver in DoD 5000.2R tequirements. This illustrates that 
the regulation is highly focused on development of systems, instead of providing 
guidance on systems life cycle management. This implies DoD policy makers are not as | 
interested in support of the portion of acquisitions that provide continuing capability after 
development. | 


2. Requirements Distribution Among Development Phases 


To continue the investigation, requirements allocated to development were 
analyzed by phases and milestones as described in DoD 5000.2R, Part I. These include 
four phases (Pre-Milestone 0, Concept Exploration, Program Definition/Risk Reduction, 
and Engineering/Manufacturing Development) and four milestone decisions (Milestones 


0, I, O, and Hy). 


SI 


Be 


Chart 1. Pareto: Number of Requirements by Each Life Cycle Function (Source: Developed by 
Researcher) | . 
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The number of functions for each phase was approximately equal as were the 
number of functions for each milestone (see Chart 2). This is to be expected given the 
iterative nature of DoD 5000.2R Part I acquisition process. Iteration is not anily required 
by DoD 5000.2R but also by the systems engineering process (Gunther, 1995). 

The Concept Exploration phase was allocated the most requirements (680). The 
phase allocated the least was pre-milestone 0 with 615. Milestone I, the exit decision for 
Concept Exploration, was allocated the most requirements of the milestones (63). 

_ Differences in numbers of requirements among the phases and milestories are due 
to some sia in requirements as system development matures. 


3. Systems Engineering Function Requirements Distribution for 
Concept Exploration Phase 


Examining one phase at a time allows further exploration of requirements drivers 
without the amplifying effects of repetition. Concept Exploration was analyzed’ for 
requirement distribution among the wiead systems engineering functions. 

The results indicate there are requirements drivers (see Chart 3). Synthesis was 
allocated 48% of Concept Exploration requirements. Synthesis is the consideration of 
alternative ways to accomplish the functional architecture. It is also the selecdon and 
documentation of the result. Concept Exploration synthesis provides decisions affecting 
system level specifications, acquisition strategy, funding profiles and other plans that lay 
out the system life cycle. 

Synthesis performed during Ganeent Exploration accounts for 10.7% of the total 


number of project requirements identified in DoD 5000.2R. 
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Chart 2. Pareto: Number of Functions by Phase of Development (Source: Developed by 
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4. Requirement Distribution for Concept Exploration Synthesis 


There are three subjects: the Project Manager (PM), the Milestone Decision 
Authority (MDA) and the User. Subject is defined here as the individual who must 
perform the required function. 

The number of Concept Exploration synthesis requirements were determined for 
these subjects (see Chart 4). The PM accounted for 97% of the total number, making this 
individual the performer of the vast majority of requirements. The PM is the primary 
subject of requirements in this regulation. This was overwhelmingly true in all queries 
made on the database, based on subject. The Project Manager performing Synthesis 
during Concept Exploration phase is allocated 10.4% of the total number of project 
requirements identified in DoD 5000.2R. 


5. Task Requirements Distribution for the PM During CE Phase 
Synthesis | 


For more detail on the emphasis minced on the PM, a distribution of requirements 
for all identified tasks to be performed was analyzed. During requirements capture, a 
common list of verbs was used to allow categorization by action. The title given these 
entries in the function list was "tasks." 

The number of requirements for the PM during Concept Exploration synthesis 
were categorized by "task." (See Chart 5.) The results indicate a weak Pareto distribution, 
singling out four tasks as the primary requirements drivers. These tasks were "use," 


“plan,” "establish," and "consider." 
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: Chart 4. Pareto: Number of Requirements by Subject for Concept Exploration Synthesis (Source: 
Developed by Researcher) 
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The majority of requirements which emphasized "use" and "consider" focused on 
directing or influencing system solutions chosen during synthesis. These tasks to be 
accomplished by the PM during Concept Exploration Synthesis account for 37.5% of the 
total number of project requirements identified in this analysis. 

Requirements emphasizing "plan" and "establish" were constraining the design of 
the development process. These tasks for the PM during this phase were inal 33.3% 
of the total number of project requirements identified in this analysis. 


6. Further Investigation of Requirements for the PM During CE Phase 
Synthesis 


Further investigation of the four driving tasks ee conducted to isolate | 
requirements drivers. Each task ns analyzed for the number of requirements by “object” 
of the task. An object . the receiver of any action taken. An example is the requirement 
to use a Work Breakdown Structure. Use is the task ai "Work Breakdown Structure” is 
the object. Objects of this nature were identified for all requirements identified in DoD - 
5000.2R. 

All four tasks identified as drivers were analyzed (Charts 6-9). These showed 
relatively flat distributions, eliminating Pareto analysis. The largest number of 
requirements allocated to any of these objects was for an integrated data management 
system (11), allowing no conclusions to be made. 

The flat distributions indicate that the chosen path of investigation with this 
functional architecture is exhausted. No further requirements drivers from DoD 5000.2R, 


based on this line of investigation, can be clearly identified. 
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Chart 5. Pareto: Number of Requirements by Task for the PM During Concept Exploration (Source: Developed by 
Researcher) 
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Chart 6. Pareto: Number of Requirements by Object for use" Tasks of the PM during Concept 


Exploration Synthesis (Source: Developed by Researcher) 
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Chart 7. Pareto: Number of Requirements by Object for "plan" Task of the PM during Concept 


Exploration Synthesis (Source: Developed by Researcher) 
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Chart 8. Pareto: Number of Requirements by Object for "establish" Task of the PM during Concept 


Exploration Synthesis (Source: Developed by Researcher) 
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Chart 9. Pareto: Number of Requirements by Object for "consider" Task of the PM during Concept 


Exploration Synthesis (Source: Developed by Researcher) 
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oF QUALITATIVE CHARACTERISTICS 


1. Implications as a Communications Tool 


To evaluate the functional architecture from a qualitative perspective, an analysis 
of DoD 5000.2R as a communication tool was performed. A strategic contingency 


communications model (Figure 9) was used to address aspects critical to accomplishing 


this regulation. 
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a) | Order to Reduce Federal Regulations 

On 11 September 1993, President W.J. Clinton ordered the executive 
branch of the federal government to reduce the number of regulations not required by law. 
The goal was reduction by 50% within 3 years. The executive order was given to 
improve federal government productivity, and to streamline operations (EO #12861, 
1993). 

DoD 5000.2R was an answer to Executive Order 12861 and was intended 


to minimize the volume of mandatory guidance (Kaminski, Coyle, Paige, Mar 1996). 


b) Objectives for Communicating 


There are three categories of objectives for government communications; 
to inform, to influence attitudes, and to affect behavior (Garnett 1997). The purposes for 


DoD 5000.2R (presented in Section II of this thesis) indicate that all three categories 


apply. 


(1) To Inform. The first objective of DoD 5000.2R is to 
infor acquisition personnel of mandatory procedures required by DoD. DoD procedures 
include a wide variety of initiatives on all processes including acquisition. A primary 
objective stated in DoD 5000.2R is to frame the acquisition process with formal reviews. 
This provides control of project progress throughout the life cycle. While this establishes 
the milestone decisions, DoD 5000.2R also includes teamwork, tailoring, empowerment, 
cost as an independent variable (CAIV), commercial product use, and best practices 
(Kaminski, Coyle, Paige, 1996). After Changes 1 and 2 of DoD 5000.2R were 


implemented, the number of DoD constraints grew with Change 3. In this change, a 
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significant number of "will" statements were changed to "shall" statements. This implies 


mandatory requirements. 


(2) To Influence Attitudes. DoD 5000.2R answers the 
concern that previous DoD acquisition policy documents were "unwieldy and too 
complex" (Kaminski, Coyle, Paige, 1996) and this fosters an attitude ee PMs to 
avoid following the regulation where possible. The framework of milestone decisions and 
other constraints were intended to be a "simplified and flexible management framework" 


(DoD 1998). 


(3) To Affect Behavior. Through mandatory procedures -- 
whether supporting controls, "themes", or statute -- the DoD 5000.2R is intended to 
standardize the acquisition project. This is done by mandating a large number of steps as 
a model to be tailored. In this way, control is maintained over the planning and execution 
of acquisition projects across all projects and program offices. | 

c) Audience 


The audience of a particular communication can be divided into three 


categories. 


(1) Immediate Audience. The immediate audience are those 
that route the message to the primary audience. For DoD 5000.2R, the immediate 
audience is the staff of the office of the Under Secretary of Defense (Acquisition and 


Technology) who assembles the document and coordinates changes. 
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(2) Primary Audience. Primary audiences are those who make 
decisions and act on information contained in the messane: The strategic communication 
model used for this analysis contains an audience profile which provides some insight to 
DoD 5000.2R intended primary audience. This profile consists of two main parts, the 
personal profile and the topic and situation profile. 


(a) Personal profile. 


The personal profile resulting from the Functional 
Database is that of a Government Project Manager with a broad technical project 
management background and experience. | 

A personal profile is used to identify personal 
characteristics of the audience. These characteristics include name, title, organizational 
role, routine, age, gender, education level, education field, professional experience, 
geographic identification, group affiliations, and preferences. 

As mentioned in this thesis, most requirements were 
identified for the Project Manager. 

In the Functional Database, there are an 
overwhelming number of requirements for technical analyses without explanation or 
instruction. These analyses imply a schema, or previous understanding of the sonia by 
the primary audience (Hirsch 1997, 51). DoD 5000.2R’s effectiveness depends on the 
audience's anaerstanding of what these analyses produce, how they are accomplished and 
how they are coordinated. 

Studies indicate successful leaders and managers 
require broad experience and competence in the field of their organization's endeavor 
(Kotter 1992, 102 ; Mintzberg 1992, 13 ; Schein 1980, 130). For technical projects, this 


implies a broad technical background, not only in training, but in experience. The 
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requirement for the PM to use Integrated Product and Process Development (formally 
called concurrent engineering) and systems engineering, both specialized engineering 
functions (OUSD A&T, 1998)(IEEE, 1994), implies significant experience and expertise 
in engineering management. 

( b) Topic and Situation Profile 

The topic and situation profile developed from the 
functional architecture is mixed between experienced professional and inexperienced 
novice. | 

The language and topics discussed indicate 
experienced technical managers are the audience. Additionally, DoD 5000.2R 
information is delivered in complex sentences. This requires a methodical analysis to | 
decipher specific requirements, and implies an audience of very experienced 
professionals, with lots of time to study the document. 

In contrast, a large number of simple requirements 
in some areas suggest an inexperienced audience. The simple areas are centered around 
~ systems engineering and the use of best practices in technology, analysis, and 
management. One version of the systems engineering process is presented in a lot of 
detail. This type of guidance, along with requirements stressing six "themes," presents an 
elementary view of one version of project management. This simple minded direction 
toward one process is indicative of what organizational studies recommend for 
management of personnel with low ability and technical knowledge (Schein 1980, 131). 
This form of direction is also seen as applicable to management of jobs with low 
technological uncertainty and low technological interdependence (interfaces with other 
organizations) (Cummings and Huse 1996, 285) . Contrary to the above, uncertainty and 


interdependence are high in DoD acquisition. 
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To confuse matters further, the systems engineering 
description in DoD 5000.2R falls far short of providing the guidance required in a 
standard, such as IEEE P1220-1994. The DoD 5000.2R systems engineering process also - 
includes requirements that are not part of the standard. Other versions of the systems 
engineering process, such as open systems design (Hitchins, 1992) or architecture dives 
design (Booch, 1996) are not mentioned. Best practices which are not included in the 
regulation far exceed those in the Functional Database. Additionally, the "themes", such 
as "Cost as an Independent Variable”, are not defined in the regulation and in fact are still 


evolving within DoD (Land 1997, 24). 


(3) Secondary Audience. Secondary audiences are those who 
are affected by decisions and actions taken by the primary audience. There is a very large 
sécondary audience to DoD 5000.2R. The procurement of military equipment qualifies as 
the largest business in the world (W ‘idavek and Caiden 1997). As the model for all new 
acquisitions, DoD 5000.2R affects millions of people around the world. The 
interpretation and execution of this regulation affects organizations from industrial 


contractors to military combat units. 
d) Management Situation 


To analyze the management situation using the communication model, 
four characteristics are identified. These characteristics are the nature of management 
routine, organizational state, primary leadership style, and organizational mission and 


culture. 
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(1) Nature of Management Routine. The nature of routine and 
standardization in DoD acquisition is one of increasing control exercised through this 
regulation. The number of requirements in the Functional Database is also indicative of 


the desire for high levels of standardization. 


(2) Organizational State. The state of DoD is one of financial 
focus. Emerging from the Cold War as the premier military power in the world, DoD 
finds itself consumed with the cost of maintaining strength at much reduced funding 
levels (Wildavsky and Caiden 1997). The DoD acquisition organization focuses on 
funding and the management of system life cycle costs. These are prominent in the 
regulation's "themes" (Kaminski, Coyle and Paige 1996) and the many requirements for » 


Cost As an Independent Variable (CAIV) and life cycle cost management. 


(3) Primary Leadership Style: The leadership style apparent in 
DoD 5000.2R consists of much more authority than democracy. The amount of freedom 
to make decisions at lower levels determines the leadership pattern of an organization. — 
The more decisions made by the top level, the more an organization displays an authority 
pattern (Tannenbaum and Schmidt 1992, 126). The large number of requirements in the 
Functional Database shifts the amount of freedom from the PM to the authors of DoD 
5000.2R. 

e) Sender 


The sender, the Secretary of Defense, possesses formal authority easily 


recognized by the audience. 
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f) Message 


| (1) Content. DoD 5000.2R contains a very large number of 
requirements for project management. This is evident from the number of requirements in 
the Functional Database. Very little language within the document is provided without a 
"shall." Each use of “shall” provides at least one more requirement and often, in DoD 


5000.2R, more than one. 


(2) Tone. This increase of authoritarian tone signals a change 
in leadership style by DoD to more of an autocratic pattern (Tannenbaum and Schmidt 


1992, 126). 


(3) Analysis. No analysis of acquisition process decisions is 


represented in DoD 5000.2R. 


(4) Style. The language used in this regulation was complex 
and, at times, convoluted. It is common for sentences to be long and complex, containing 
multiple requirements. Requirements to conduct analyses are implied by a statement 
requiring reports of the analyses results. Backing into requirements in this way ensures 
many mistakes will be made. The explicit permission to tailor many requirements 
presents additional confusion: exactly what is mandatory and what is not? Mandatory 
requirements are scattered among those that may be tailored. Just to understand what is 
actually mandatory requires a lot of time evaluating DoD 5000.2R. Beginning with a high 
level model of the whole process allows. tailoring without fear of omissions. Those 
requirements that can be tailored are, in essence, guidance. A major problem is the 


minimal technical and managerial knowledge presented in this. regulation. 
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(5) Quality of Acquisition Requirement Statements. Due to the 
large number of project management requirements in the relatively short DoD 5000.2R, a 
short analysis of this regulation as a requirements document was conducted. Sommerville 
and Sawyer (1997) provide a set of good practices for documenting requirements (Figure 


10). 


Requirements Documentation 
Checklist 





Define Standard Templates 


Use Language Simply, 
Consistently and Concisely 


Use Diagrams 


Supplement Natural 
Language — 


Specify Requirements 
Quantitatively 





Figure 10. Requirements Documentation Best Practices 
(Sommerville and Sawyer 1997) 
(a) Define Standard Templates 
The statements in DoD 5000.2R do not follow a 


standard template. Requirements statements vary in complexity and form throughout the 
document. 

_ A:standard description of a requirement increases 
completeness of requirement statements and makes them easier to read (Sommerville and 


Sawyer 1997, 141). (This method was used to establish the requirements baseline for this 
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thesis.) Database fields were established to extract DoD 5000.2R requirements into a 
standard template. 


(b) Use Language Simply, Consistently and 
Concisely 


The regulation was consistent in its use of "will" 
and "shall" and terms common to acquisition. The language was very complex and 
unclear, especially when describing multiple requirements with very long sentences. 

Simple and concise language makes the 
requirements easier to read and understand. It reduces the amount of misunderstanding in 
the document. 

(c) Use Diagrams 

There are no diagrams or figures in DoD 5000.2R. 
The use of diagrams would provide clear intent in a number of areas. (An example ts 
clarification of the term "iterative," when applied to systems engineering.) 

_ When describing structure or relationships, the use 


_of diagrams is more effective than text and leads to twice the understanding. — 


(d) Supplement Natural Language with Other 
Descriptions of Requirements 


This regulation used no formulae, decision tables, or 
charts in the main body of the text. Descriptions of the acquisition process in Part I would 
have benefited from graphic elements or illustrations to amplify the text. 

Standard notation, such as decision tables and 
charts, are more concise, clear and less likely to be misinterpreted than text. This is 
especially true when communicating with experienced professionals in the subject 


domain (Sommerville and Sawyer 1997, 141). 
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(e) Specify Requirements Quantitatively 

There were no quantitative performance standards 
established in the regulation, other than costs and undefined exit criteria required for 
reporting back to the MDA. Measures of effectiveness, even if presented as goals, would 
provide a means of objectively understanding the constraints of DoD 5000.2R. "To the 
maximum extent possible" and "as applicable” are, perhaps, necessarily vague but would 
benefit from a hard goal for DoD acquisitions. Quantitative requirements communicate 
precise constraints to both the developer and the oversight organizations (Sommerville 
and Sawyer 1997, 141). 

| g) Choice of Media 

The media chosen was a written regulation distributed in capee and. 
electronic formats. The copy used for this thesis was electronicly downloaded from the 
World Wide Web from the USD(A&T) server. 

DoD 5000.2R was accompanied by the Defense Acquisition Deskbook 
and internet resources that include related information but not requirements. The choice 
to support the written regulation with other information sources indicates a "rich media." 
This suggests that the message included is deemed by DoD to be equivocal and complex 
(Trevino, Daft and Lengel 1997, 34). The size of the Functional Database confirms the 
, assumption of complexity. However, DoD 5000.2R prohibits supplements by any DoD 
component and limits implementing documentation to a minimum (DoD 1998). This 
prohibition implies the regulation is intended as a stand-alone document. As discussed 


earlier, the style of this document is essentially a list of requirements. The use of lists for 
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equivocal, complex messages provides too few cues to the audience, making its 


effectiveness one of "Communication Failure" (Trevino, Daft and Lengel 1997, 34). 
There are other complementary efforts taken to make me of the 
acquisition process more understandable. World Wide Web access to regulations were 
established to allow instant updates of information from the project office. A Project 
Managers Bill of Rights was written to provide a sense of security to PMs during massive 
changes in acquisition policy. An Acquisition Deskbook, an ever growing digital 
reference program, was strengthened, presented i is being updated at least twice a year. 
The Deskbook provides project offices with a full regulation reference, lessons learned, 


dictionary and step by step processes. 


h) Length 


The length of DoD 5000.2R is insufficient for the complex message it 
contains. DoD 5000.2R would be significantly longer if it used a good documentation 


method for requirements such as that in Sommerville and Sawyer (1997). 


l) Timing 
The timing associated with this regulation has been an average of one 


change every six months. 


Ze Implications of DoD Corporate Strategy for Acquisition 


The implications of the DoD 5000.2R document on DoD strategy based on level 


of constraint of acquisition processes are examined in this section. 
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a) Strategy Defined 


Quinn (1996) defines strategy as "the pattern or plan that integrates an 
organization's major goals, policies, and action sequences into , cohesive whole." DoD. 
intends to establish "stable, affordable, and well-managed" acquisition programs (DoD 
1998). The process to accomplish this is stated as a simplified and flexible management 
framework for use by the acquisition projects. Communicating this femnework is the 


stated purpose of DoD 5000.2R. 


(1) Simplified and Flexible Management Framework. The 
management framework defined in DoD 5000.2R, Part I provides definitions of a process 
that is dominated by milestone decisions. Other parts of the regulation further define the 
phases of acquisition and required functions for those phases. Specific requirements may 


be tailored, an option which creates flexibility in this process. 


(2) Umbrella Strategy. The intent of the DoD 5000.2R strategy 
is to provide broad bounds for acquisition projects. Within these bounds, the projects 
would use best practices of industry, academia, and government to provide efficient 
solutions to materiel needs (Kaminski, Coyle and Paige 1996; DoD 1998). Mintzberg and 
Waters (1985) refer to this type of strategy as an "Umbrella Strategy.” This overall 
Strategy is partly deliberate and partly emergent in nature. In DoD's case, the deliberate 
Strategy is provided by DoD 5000.2R, which imposes bounds on PM action. The 
emergent strategy is formed by a sattei of innovative actions which are taken by PMs 


executing their projects. 
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b) DoD Actual Strategy 


The strategy observed from the Functional Database is one of confusing, 
detailed processes articulated by the central leadership, DoD, and backed up by formal 
controls to ensure implementation. While an intended strategy drives goals and actions, 
the result of those actions and any obtained goals are the actual strategy. Thus the actual 


strategy can be much different than the one intended (Mintzberg 1996, 10). 


(1) Analysis Driven. | Approximately one third of all 
requirements in the Functional Database are for analysis and synthesis. This indicates the 
DoD's strategy relies on PMs performing a large amount of analysis to guide decisions 
such as the synthesis of alternatives and milestone approvals. But no guides or processes 


are defined for performing this analysis. 


(2) Strategic Planning vs. Strategic Thinking. The fares 
number of standard analyses and processes required by DoD 5000.2R promote confusion 
over strategic thinking or planning. There is, however, a common mistake in expecting 
innovative managers to use the same models as those defined in this analysis. Mintzberg 
(1996) observes vn the essence of strategic thinking is thinking "outside the box.” This 
"box" is the set of models defined by standard analyses. Models are key to planning 
action. Strategic thinking, however, requires using new’ models and old ones in new 
ways. DoD requires many standard models be used by PMs. These standard models 
control analyses, from how they construct Work Breakdown Structures to what 
alternative solutions they ‘consider (DoD 1998). This structured approach restricts the 


PM's ability to employ strategic thinking. Tailoring allows movement back to strategic 
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thinking for those PMs with resources and time to tailor the immense Functional 


Database. 


(3) Trends in DoD. Increased constraints are evident by the 
fact that no requirements were removed by Change 3, while a number were added (DoD 
1998). Change 3 indicates that the number of constraints on the DoD acquisition process 


is creeping UPWARD. 


(4) Planned Strategy. While an Umbrella Strategy is intended 
by DoD, this regulation imposes more of a Planned Strategy on PMs. Mintzberg (1996) 
defines a Planned Strategy as one where precise intentions are formulated and articulated 
by a central leadership. Actions of subordinates are reviewed by formal controls to ensure 
surprise-free execution. Such a strategy is suited for benign, controllable, or predictable 
environments. This planned strategy is nearly all deliberate, with little room for emergent 
Strategy by subordinates. Current DoD leadership stresses the need for reform of 
acquisition, with strategies determined at the DoD level (Gansler 1998, 12). This is 
further whee that DoD is pursuing a Planned Strategy. Thus we have conflict 


between what DoD policy makers say and what they do in DoD 5000,2R. 


D. CHAPTER SUMMARY 


A quantitative and qualitative analysis of the Functional Database was conducted. 
The quantitative analysis used a Pareto analysis of requirement count, by category. This 
allowed determination of DoD's emphasis on mandatory functions. From a siaaaiiatiads 
penepecnne, DoD is emphasizing control ove synthesis portions of each acquisition 


phase. This control is primarily directed at design of the acquisition process and the 
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system alternative sources. Qualitative analysis was performed on DoD 5000.2R and the 
Functional Database from two perspectives. The first was as a communication tool to 
identify characteristics of DobD's intentions. The second was a complementary 
examination of the implied strategy DoD is pursuing for acquisition. 

Qualitative analysis indicates that DoD is sending mixed ‘signals with this 
regulation. On one hand, the complex nature of the mandatory slbiibe process 
demands highly competent technical managers as an audience. On the other hand, the 
large number of constraints imposed by DoD indicate a concern that acquisition managers 


are inexperienced and need “spoon feeding.” 
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V. CONCLUSION AND RECOMMENDATION 


A. CONCLUSIONS AND ANSWERS TO RESEARCH QUESTIONS 


1. Primary Question 


To what extent does the DoD 5000.2R constrain evieahel manager? 

DoD 5000.2R "Mandatory Procedures for Major Defense Acquisition Programs 
(MDAPs) and Major Automated Information System (MAIS) Meas Programs" is a 
complex regulation with a very large number of constraints on project managers. The 
recent Change 3 to DoD 5000.2R shows a trend of increasing that level of constraint. 

The level of detail within DoD 5000.2R constraints is mixed. While not an 
extremely detailed document, the regulation is over-constraining for an experienced | 
technical manager, too complex for Sanco below that level of expertise, and too 
conceptual for the direction of inexperienced novices. Borrowing from parts of several 
established processes, this regulation provides an inadequate level of process detail to 


allow prudent tailoring. 
2. Subsidiary Questions 


a) DoD 5000.2R Project Management Requirements 


What are the requirements included in the 5000.2R that affect defense 


acquisition project management? 
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There are 862 specific requirements on the acquisition program covering 


the entire system life cycle. These requirements are listed in Appendix A. 


b) DoD 5000.2R Project Management Process 


What common functions are required to be performed by project 
management? 

What requirements must these functions meet? 

When repeated as required during phases of development, the identified 
requirements impose 3,040 individual constrained functions. The os of these 


constrained functions are to be accomplished during development. 


Cc) Quantitative Analysis of Findings 


What are the quantities and distribution of requirements among 


project management functions? 


Pareto analysis reveals a primary focus of DoD 5000.2R requirements is 
the direction or influence on both system solutions and the development process used by 


the PM. 


d) Qualitative Analysis of Findings 

How effective is DoD 5000.2R as a communication tool? 

A variety of other media is available to assist understanding defense 
acquisition. However, no other document or media is allowed to supplement DoD 
5000.2R. This mandate makes reliance on other sources unofficial and at the sole risk of 


the PM. As a stand alone document, it is too lean a form of media for the complex 
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message it contains. Additionally, it is poorly written as a requirements document, a 
defect which ensures omissions and misinterpretations of the intended system solution 
and development process. A_ strategic contingency model for government 
communications rates this document as a “Communication Failure” as a stand alone 
regulation. 

What implications on DoD acquisition policy can be obtained from 
this document? 

Because the document Gsclises on constraining system solutions and 
development process, jt raises concern that DoD does not view project managers as 
competent and capable ‘i managing acquisitions. This may explain DoD's acquisition 
policy movement from an umbrella strategy (stated in acquisition reform as leaving 
details to the PM) to one that is planned aid executed by an increasingly ‘autocratic 
management style. By mandating good practices, DoD 5000.2R is preventing the use of 
best practices. Best practices are fluid, growing in number and are unique to each 


acquisition domain. 


B. RECOMMENDATIONS | 
1. Determine the Primary Audience for DoD 5000.2R 


If competent project personnel are the audience, then this regulation should be 
focused on policy, greatly reduced in detail. If the view of project office personnel is one 
of incompetence, then go further than DoD 1 5000.2 and provide a step-by-step cookbook 


with thousands of clear requirements. A particular audience must be established before 
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this document will successfully elicit behavior from its project personnel. Otherwise, 
personnel will either be over-constrained or given too little guidance. 


Z Hire Program Managers in Whom DoD is Confident 


The evident lack of confidence in current Program and Project Managers has only 
one clear solution. It is true that DAWIA will provide some of the education required for 
competent management and systems engineering. However, PM positions must be 
seriously viewed as critical by DoD. The implication of this includes much that is true for 
industry key positions, compensation, office location, and career advancement conducive 
to sitractine talented technical managers. Current relative aspects of Government PM 
positions -- high stress, low pay; undesireable locations and no clear career path -- will 


seldom attract and keep talented, technically competent managers. 


3. Assign One Organization Authority for Editing the Contents of DoD 
5000.2R | : 


The complex sentence structure a implied requirements should be screened out 
by one organization under the Office of the Secretary of Defense. That one organization 
should be manned by systems engineers competent in writing and managing 
requirements. This organization should also be held responsible by the eeauisition 
organization for clarification of DoD regulation content on a continuing basis as a 
service. Clarifications should carry the same weight as the regulation. 


4. Rewrite DoD 5000.2R as a Performance Document (One Requirement 
per Sentence) 


Assuming a competent acquisition organization, DoD 5000.2R should describe 


what is required, not how to achieve it. The issue of competence of DoD personnel 
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responding to this regulation should be the same as contractor personnel responding to a 
specification. Through specifications, contractors are told only the result to be achieved, 
not how to achieve that result. With comparable competence, DoD acquisition personnel 
should be given a similar scope of direction. 

Follow best practices in rewriting DoD 5000.2R to allow understanding. Use 
personnel competent in communicating requirements such as systems engineers to 
manage the rewrite. The use of standard templates for mandatory statements, simple, 
consistent and concise language, diagrams and figures, decision tables and charts, and the 
inclusion of sistas in these acquisition requirements are required for acquisition 


personnel to understand what is required of them. 


C. | RECOMMENDATIONS FOR FURTHER STUDY 


1. Comparison of DoD 5000.2R Requirements Baseline with a DoDI 
5000.2 Requirements Baseline 


Perform requirements analysis and functional analysis of DoDI 5000.2 and 
compare with these thesis results. Comparisons would be valuable in the number of 
requirements, the distribution of requirements over the life cycle, and implied 
‘management philosophies. These comparisons would provide indications of trends or 


latent requirements in the migration to current acquisition reform regulations. 


2. Project Office Response to. DoD 5000.2R 


Poll project offices for response to this thesis and obtain whether they are 


accounting for accomplishment of the large number of requirements. If so, the methods 
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they are using should be examined. The information would provide cost data for 
evaluation of the cost imposed on project offices by this regulation. If they are not taking 
these requirements into consideration, the percentage of unofficial tailoring and tailoring 


without analysis can be deduced. 


o DAWIA Status 


Poll higher DoD officials on their opinion of the competency of acquisition 
personnel, especially PMs. A comparison of the answer with trends in DAWIA training 
status, number of personnel per year and number of hours per person, would provide a 


test for DAWIA alignment with DoD management policy. 


4. Rewrite of DoD 5000.2R 


Apply the recommendations of this thesis (especially the Requirements Baseline 
in Appendix A) to sounds DoD 5000.2R. This resulting document would conform to 
acceptable communication and requirement documentation standards. Additionally, 
provide recommendations for proposed adjustments to constraints imposed by public law. 


5. Acquisition Measures of Effectiveness 


Identify applicable measures of effectiveness for use in DoD 5000.2R. These 
measures should allow high level military and civilian officials to determine the status of 


an acquisition program from perspectives implied in the current DoD 5000.2R Change 3. 
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APPENDIX. REQUIREMENTS DATABASE FROM DOD 53000.2R 


Notes: 1. This listing is sorted by section of DoD 5000.2R. 


2. Requirements numbers in this Appendix were assigned during initial identification of 
requirements. Later combination of like requirements cause those numbers to repeat 
with omission of the original requirement number. Additionally a few derived 


requirements were deleted after re-evaluation leaving gaps in the requirements 
number sequence. 
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Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
Memo The MDA shall approve proposed tailoring. 001 MDA approve process tailoring 
1.1 Purpose However, cognizant of this model, the Program Manager 002 Both structure process through a series of 
(PM) and the Milestone Decision Authority (MDA) shall phases 
structure the MDAP or MAIS to ensure a logical 
progression through a series of phases designed to 
reduce risk, ensure affordability, and provide adequate 
information for decision-making that will provide the 
needed capability to the warfighter in the shortest 
practical time. 
PMs and MDAs for other than MDAPs or MAISs shall 003 . Both adhere process generally, other than 
generally adhere to the process described in this part; MDAPs 
however, they shall tailor the process, as appropriate, to 
best match the conditions of individual non-major 
. programs. 
004 Both tailor process 
1.2 Overview of The acquisition process shall be structured in logical 005 Both structure process in logical phases 
the Acquisition phases separated by major decision points called 
Management milestones. 
Process 
006 Both structure process phases separated by 
major decision points 
The process shall begin with the identification of broadly 007 Both structure process begin with broadly 
stated mission needs that cannot be satisfied by stated mission needs 


nonmaterie! solutions. 
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Applicable DoD 5000.2R Statements 


1.2 Overview of 
the Acquisition 
Management 
Process 


Threat projections, system performance, unit production 
cost estimates, life cycle costs, interoperability, 
cost-performance-schedule trade-offs, acquisition 
strategy, affordability constraints, and risk management . 
shall be major considerations at each milestone decision 
point, including the decision to start a new program. 


Extracted Requirements 


No. 
008 


009 


010 


011 


012 


013 . 


014 


015 


‘016 


Subject 


Both 


Both 


Both 


Both 


Both 


Both 


Both 


Both 


Both 


Task 


consider 


consider 


consider 


consider 


consider 


consider 


consider 


consider 


consider 


Object 
Threat projections 


system 
performance 


unit production 
cost estimates 


life cycle costs 


interoperability 


cost-performance- 
schedule 


acquisition strategy 


affordability 
constraints 


risk management 


Modifier 


at each milestone 
decision point 


at each milestone 
decision point 


at each milestone 


decision point 


at each milestone 
decision point 


at each milestone 
decision point 


at each milestone 
decision point 


at each milestone 
decision point 


at each milestone 
decision point 


at each milestone 
decision point 


Using 


SL 


Applicable DoD 5000.2R Statements 


1.2 Overview of 
the Acquisition 
Management 
Process 


At program initiation, and after consideration of the 
views of the Working-Level Integrated Product Team 
(IPT) and Overarching IPT members, the PM shall 
propose, and the MDA shall consider for approval, the 
appropriate milestones, the level of decision for each 
milestone, and the documentation needed for each 
milestone. 


This proposal shall consider the size, complexity, and 
risk of the program. 


Extracted Requirements 


No. 


017 


018 


019 


020 


021 


022 


023 


024 


Subject 


PM 


PM 


PM 


PM 


PM 


MDA: 


PM 


PM 


Task 
consider 


consider 


propose 


propose 


propose 


consider for 
approval 


consider 


consider 


Object 


views of the 
Working-Level 
integrated Product 
Team (IPT) 


views of 
Overarching IPT 
members 


appropriate 
milestones 


level of decision 
for each milestone 


documentation 
needed for each 
milestone 


documentation 
needed for each 
milestone 


size of the 
program 


complexity of the 
program 


Modifier 


At program initiation 


At program initiation 


At program initiation 


At program initiation 


At program initiation 


At program initiation 


proposal 


proposal 


Using 
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Applicable DoD 5000.2R Statements 


1.2 Overview of This proposal shalt consider the size, complexity, and 
the Acquisition risk of the program. 

Management 

Process 


The determinations made at program initiation shall be 
reexamined at each milestone in light of then-current 
program conditions. 


1.3 Categories of | Upon initiation, size and complexity shall generally 


Acquisition categorize acquisition programs. The categories are: 
Programs and ACAT |, ACAT IA, ACAT Ii, ACAT Ill 
Milestone Decision 

Authorities 

1.4 Acquisition All programs, including highly sensitive classified, 
Phases & cryptologic, and intelligence programs, shall accomplish 


Accomplishments _ certain core activities described throughout this 
Regulation. How these activities are conducted shall be 
tailored to minimize the time it takes to satisfy an 
identified need consistent with common sense and | 

- sound business practice. 


Tailoring shall give full consideration to applicable 
Statutes. 


The number of phases and decision points shall be 
tailored to meet the specific needs of individual PMs, 
based on objective assessments of a program's 
category status, risks, the adequacy of proposed risk 
management plans, and the urgency of the user's need. 


Extracted Requirements 


No. 
025 


026 


027 


028 


029 


030 


031 


Subject 


PM 


Both 


Both 


PM 


Both 


Both 


Both 


Task 
consider 


reexamine 


categorize 


accomplish 


tailor 


taifor 


tailor 


Object Modifier Using 


. tisk of the program proposal 


determinations 


project based on ACAT 
process core activities 
process minimize time 
process IAW statutes 
process based on program's 


category status 
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Applicable DoD 5000.2R Statements 


1.4 Acquisition 
Phases & 
Accomplishments 


1.4.2 Phase 0: 
Concept 
Exploration 


The number of phases and decision points shall be 
tailored to meet the specific needs of individual PMs, 
based on objective assessments of a program's 


_ Category status, risks, the adequacy of proposed risk 


management plans, and the urgency of the user's need. 


Tailored acquisition strategies may vary the way in 
which core activities are to be conducted, the formality 
of reviews and documentation, and the need for other 
supporting activities. ACAT II and II! program managers 
shall work with their decision authorities to tailor any 
documentation and decision points to the needs of the 


individual program. 


Analysis of alternatives shall be used as appropriate to 
facilitate comparisons of alternative concepts. The most 
promising system concepts shall be defined in terms of 
initial, broad objectives for cost, schedule, performance, 

software requirements, opportunities for tradeoffs, 
overall acquisition strategy, and test and evaluation 
Strategy. 


Extracted Requirements 


No. 
032 


033 


034 


004 


036 


037 


038 


Subject 
Both 


Both 


Both 


Both 


Both 


PM 


PM 


Task 
tailor 


assess 


assess 


tailor 


uSG 


analyze 


analyze 


Object Modifier Using 
process risks 
process | adequacy of proposed 
risk management 
plans 
process urgency of the user’s 
need 
process 
analysis of as appropriate 
alternatives 
cost as appropriate analysis of 
alternatives 
schedule as appropriate analysis of 


alternatives 
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Applicable DoD 5000.2R Statements 


1.4.2 Phase 0: 


Concept 
Exploration 


1.4.3 Phase I: 


Analysis of alternatives shall be used as appropriate to 
facilitate comparisons of alternative concepts. The most 
promising system concepts shall be defined in terms of 
initial, broad objectives for cost, schedule, performance, 

software requirements, opportunities for tradeoffs, 
overall acquisition strategy, and test and evaluation 
strategy. 


During this phase, the program shall become defined as 


Program Definition one or more concepts, design approaches, and/or 
and Risk Reduction parallel technologies are pursued as warranted.. 


1.4.4.1. Low Rate 
Initial Production 


LRIP quantities for all ACATs shall be minimized. 


Extracted Requirements 
Subject Task 


No. 
039 


040 


041 


042 


043 


044 


056 


The LRIP quantity (with rationale for quantities exceeding 057 


10% of the total production quantity documented in the 
acquisition strategy) shall be included in the first SAR 
after its determination. 


PM 


PM 


PM 


PM 


PM 


PM 


Both 


Both 


analyze 


analyze 


analyze 


analyze 


analyze 


define 


plan 


plan 


Object 
performance 


software 
requirements 


opportunities for 
tradeoffs 


overall acquisition 
strategy 


test and evaluation 


Strategy 


concept(s) 


LRIP quantities 


¥ 


LRIP quantities 


Modifier Using 

as appropriate analysis of 
alternatives 

as appropriate analysis of 
alternatives 

as appropriate analysis of 
alternatives 

as appropriate analysis of 
alternatives 

as appropriate analysis of 
alternatives 


minimize quantity 


in first SAR with SAR 
rationale if over 10% 
total production 
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Applicable DoD 5000.2R Statements 


1.4.4.1 Low Rate 
Initial Production 


1.4.5 Phase ill: 
Production, 
Fielding/Deploymen 
t, and Operational 
Support 


1.4.5.1 Operational 
Support 


The LRIP quantity (with rationale for quantities exceeding 

10% of the total production quantity documented in the 
acquisition strategy) shall be.included in the first SAR 
after its determination. 


Deficiencies encountered in Developmental Test and 
Evaluation (DT&E) and Initial Operational Test and 
Evaluation ((OT&E) shall be resolved and fixes verified. 


A follow-on operational testing program that assesses 
performance and quality, compatibility, and 
interoperability, and identifies deficiencies shall be 
conducted, as appropriate. 


Extracted Requirements 
Subject Task 


No. 


058 Both 


. 062 


063 


064 


065 


066 


067 


PM 


PM 


PM 


PM 


PM 


PM 


plan 


resolve 


verify 


conduct 


assess 


assess 


assess 


Object 


LRIP quantities 


deficiencies 


deficiencies 


follow-on - 
operational test 
program 


performance 


quality 


compatibility 


Modifier Using 
<= 10% total SAR 
production 


encountered in 


DT&ENOT&E 

are fixed 

as appropriate follow-on 
operational 
test program 

as appropriate follow-on 
operational 
test program 

as appropriate follow-on 


operational 
test program 
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Applicable DoD 5000.2R Statements 


1.4.5.1 Operational 
Support 


1.4.5.2 
Modifications 


A follow-on operational testing program that assesses 
performance and quality, compatibility, and 
interoperability, and identifies deficiencies shall be 
conducted, as appropriate. 


Any modification that is of sufficient cost and complexity 
that it could itself qualify as an ACAT | or ACAT IA 
program shall be considered for management purposes 


. aS a separate acquisition effort. 


1.4.6 
Demilitarization and 
Disposal 


During demilitarization and disposal, the PM shall ensure 
materiel determined to require demilitarization is 
controlled and shall ensure disposal is carried out in a 
way that minimizes DoD’s liability due to environmental, 
safety, security, and health issues. 


Extracted Requirements 


No. 
068 


069 


072 


073 


074 


075 


076 


077 


Subject 
PM 


PM 


MDA 


PM 


PM 


PM 


PM 


:PM 


Task 
assess 


identify 


structure 


contro! 


execute 


execute 


execute 


execute 


Object 
interoperability 


deficiencies 


modification 


demil material 


disposal 


disposal 


disposal 


disposal 


Modifier Using 
as appropriate follow-on 
operational 


test program 


as appropriate follow-on 
operational 
test program 


as separate 
acquisition effort if 
ACAT | or ACAT IA 


minimize DOD 
environmental liability 


minimize DOD safety 
liability 


minimize DOD security 
liability 


minimize DOD health 
issues liability 
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Applicable DoD 5000.2R Statements 


1.5 Milestone 
Decision Points 


1.5.2 Milestone |: 


Approval to Begin 
a New Acquisition 
Program 


1.5.3 Milestone II: 


Approval to Enter 
Engineering and 
Manufacturing 
Development 


The MDA shall establish tailored milestone decision 
points for each acquisition program as early as possible 
in the program life cycle. 


At each milestone or program review, the MDA shall 
determine that the program being reviewed is 
progressing satisfactorily and is stilt required under the 
current DoD Strategic Plan 


Acquisition strategy; 


Acquisition Program Baseline (APB) (10 USC 2435 , for 
ACAT 1), including Cost as an Independent Variable 
(CAIV)-based objectives, and, 


Phase | exit criteria. 


The LRIP strategy and decision authority shall be 
considered at this milestone. 


Extracted Requirements 


No. 
078 


079 


080 


081 


082 


083 


084 


085 


Subject 
MDA 


MDA 


MDA 


MDA 


MDA 


MDA 


MDA 


MDA 


Task 
tailor 


determine 


determine 


approve 


approve 


approve 


approve 


consider 


Object Modifier Using 
milestone decision as early as possible 

points 

project progressing 


satisfactorily 


project still required DOD Strategic 
, Plan 


acquisition strategy 


APB 


CAIV-based APB 
objectives 


Phase | exit criteria 


LRIP strategy 
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Applicable DoD 5000.2R Statements 


1.5.3 Milestone tl: Acquisition strategy; 
Approval to Enter 

Engineering and 

Manufacturing 

Development 


’ APB (10 USC 2435 , for ACAT 1), including CAIV-based 
objectives; 


Phase I! exit criteria; 


LRIP quantities (10 USC 2400 )"*; and 


- Waiver from full-up, system-level LFT&E, if applicable 
(10 USC 2366 ). 


1.5.4 Milestone Ill: At this milestone, the MDA shall approve the following: 
Production or 

Fielding/Deploymen 

t Approval 


Acquisition strategy, 


APB (10 USC 2435 , for ACAT 1), including CAIV-based 
objectives, 


Extracted Requirements 


No. 
081 


082 


088 


089 


090 


091 


092 


081 


082 


Subject 
MDA 


MDA 


MDA 


MDA 


MDA 


MDA 


MDA 


MDA 


MDA 


Task 
approve 


approve 


approve 


approve 


approve 


approve 


approve 


approve 


approve 


Object Modifier 
acquisition strategy 


APB 


CAIV-based 
objectives 


Phase Il exit criteria 


LRIP quantities 


waiver from as appropriate 
full-up, system- 
level LFT&E 


acquisition strategy 


APB 


Using 


APB 


98 


Applicable DoD 5000.2R Statements 


1.5.4 Milestone Hl: 
Production or 
Fielding/Deploymen 
t Approval 


1.6 Integrated 
Product Teams 


No. 


APB (10 USC 2435 , for ACAT 3), including CAIV-based 095 
objectives, 


Phase III exit criteria, if appropriate, and 096 


Provisions for evaluation of post-deployment 097 
performance (GPRA ; CCA; and PRA ). 


The Secretary of Defense has directed that the 098 
Department perform as many acquisition functions as 
possible, including oversight and review, using IPTs. 

These IPTs shall function in a spirit of teamwork with 
participants empowered and authorized, to the maximum 
extent possible, to make commitments for the 

organization or the functional area they represent. 


When IPTs include representatives from organizations 099 
other than the federal government, PMs shall comply 
with the Federal Advisory Committee Act (FACA). 


In addition, PMs shall also remember that the participation 100 
of a contractor or a prospective contractor on a IPT 

shail be in accordance with other statutory ) 
requirements, such as procurement integrity rules. 


101 


Subject 
MDA 


MDA 


MDA 


Both 


PM 


PM 


-PM 


Task 
approve 


approve 


approve 


execute 


execute 


execute 


execute 


Extracted Requirements 


Object 


CAIV-based 
objectives 


Phase fll exit 
criteria 


provisions for eval 
of post-deployment 


‘performance 


project 


project 


project 


project 


Modifier 


as appropriate 


GPRA, CCA, PRA 


maximum extent 
possible 


IAW FACA 


IAW procurement 
integrity rules 


[AW statutory 
requirements 


Using 
APB 


IPTs 


IPTs 


IPTs 


IPTs 
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Applicable DoD 5000.2R Statements 


1.6 Integrated 
Product Teams 


2.2 Intelligence 
Support 


Prospective contractor involvement on !PTs shail be 
reviewed by the Component's legal advisor. 


When acquisition programs are initiated in response to a 
military threat, they shall be based on authoritative, 
current, and projected threat information. 


Early and continued collaboration among the intelligence, - 
requirements generation, and acquisition management 
communities shail be maintained to ensure the timely 
availability of validated threat information. This 
collaboration shall include joint examination of critical 
intelligence categories that could significantly influence 
the effective operation of the deployed system. 


Extracted Requirements 


No. 
102 


103 


104 


105 


106 


107 


108 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


consider 


execute 


execute 


execute 


consider 


consider 


consider 


Object Modifier 

legal advice when prospective 
involvement of 
contractor on IPT's 

project when in response to 
military threat 

project when in response to 
military threat 

project when in response to 
military threat 

intelligence 

community 


requirements 
generation 
community 


acquisition 
management 
community 


Using 
Component's 
legal advisor 


authoritative 
threat 
information 


current threat 
information 


projected 
threat 
information 


joint 
examination of 
Critical 
intelligence 
categories 


joint 
examination of 
critical 
intelligence 
categories 


joint 
examination of 
critical 
intelligence 
categories 
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Applicable DoD 5000.2R Statements 


2.2 Intelligence 
Support 


Evaluation of 
Command, Control, 
Communications, 
Computers, 
Intelligence, 
Surveillance, and 
Reconnaissance 
(C4ISR) Support 


Initial system threat assessments shall be prepared by 
DoD Components to support program initiation usually at 
Milestone I, Approval to Begin a New Acauisition 
Program, and maintained in a current and approved or 
validated status throughout the acquisition process. 


They shall be system-specific to the degree of system 
definition at the time the assessment is made and 
address the projected threat at IOC and IOC plus ten 
years. 


A C4l support plan’shall be prepared for all weapons 
systems/programs that interface with C4l systems. The 
C4i Support Plan shall include a system description, 
employment concept (including targeting, battle damage 
assessment, and bomb impact assessment 
requirements), operational support requirements 
(including C4l, testing, and training), interoperability and 
connectivity characteristics, management, and 
scheduling concerns. 


Extracted Requirements 


No. Subject 


109 PM 


110 PM 


111 PM 


112 PM 


113 PM 
114 PM 


115 PM 


Task 


assess 


update 


assess 


plan 


describe 


describe 


describe 


Object 
threat 


threat 


threat 


C4 


system 


employment 
concept 


targeting 
requirements 


Modifier - 


at IOC and IOC plus 
ten years 


Using 


threat 
assessment 


threat 
assessment 


C4l Support 
Plan 


C4l Support 
Plan 


C4{i Support 
Plan 


C4! Support 
Plan 
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Applicable DoD 5000.2R Statements 


Evaluation of 
Command, Control, 
Communications, 


Computers, 
Intelligence, 


Surveillance, and 
Reconnaissance 
(C4ISR) Support 


A C4l support plan shall be prepared for all weapons 
systems/programs that interface with C4l systems. The 
C4! Support Plan shail include a system description, 
employment concept (including targeting, battle damage 
assessment, and bomb impact assessment 
requirements), operational support requirements 
(including C41, testing, and training), interoperability and 
connectivity characteristics, management, and 


scheduling concerns. 


Extracted Requirements 


No. 


Subject 


116 PM 


117 


118 


119 


120 


121 


122 


123 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
describe 


describe 


describe 


describe 


describe 


describe 


describe 


describe 


Object 


battle damage 
assessment 
requirements 


bomb impact 
assessment 
requirements 


operational support 


C4l testing 


C4l training 


interoperability 


connectivity 


characteristics 


management 
concerns 


Modifier 


Using 


C4! Support 
Plan 


C4li Support 
Plan 


C4l Support 
Pian 


C4l Support 
Plan 


C4l Support 
Plan 


C4! Support 
Plan 


C4l Support 
Plan 


C4l Support 
Plan 
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Applicable DoD 5000.2R Statements 


Evaluation of 
Command, Control, 
Communications, 
Computers, 
Intelligence, 
Surveillance, and 
Reconnaissance 
(C4iSR) Support 


A C4} support plan shall be prepared for all weapons 
systems/programs that interface with C4! systems. The 
C4l Support Plan shall include a system description, 
employment concept (including targeting, battle damage 
assessment, and bomb impact assessment 
requirements), operational support requirements 
(including C41, testing, and training), interoperability and 
connectivity characteristics, management, and 
scheduling concerns. 


An evaluation of compatibility, interoperability, 
integration, and intelligence support for targeting 
requirements shall be accomplished for all weapons, 
systems/programs noted above (see CJCSI 3170.04 
and CJCSI 6212.01A ). | ) 


In accordance with CUCSI 3170.01 , C4ISR requirements 
shall be reviewed and updated, as necessary, at every 
milestone decision and whenever the concept of 
operations or intelligence requirements change. 


Extracted Requirements 


No. 
124 


125 


126 


127 


128 


129 


130 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Subject Task 


describe 


evaluate 


evaluate 


evaluate 


evaluate 


update 


update 


Object Modifier 


scheduling 
concerns 


compatibility 


interoperability 
integration support 


intelligence support 
for targeting 
requirements 


C4ISR as necessary 
requirements 


C4ISR concept of operations 
requirements change 


Using 


C4! Support 
Plan 
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Evaluation of 
Command, Control, 
Communications, 
Computers, 
Intelligence, 
Surveillance, and 
Reconnaissance 
(C4ISR) Support 


2.3 Requirements 
Evolution 


Extracted Requirements 


In accordance with CJCSI 3170.01 , C4ISR requirements 131 


shall be reviewed and updated, as necessary, at every 
milestone decision and whenever the concept of 
operations or intelligence requirements change. 


System performance objectives and thresholds shall be 
developed from, and remain consistent with, the initial 
broad statements of operational capability. ; 


The requirements shall be refined at successive 
milestone decision points, as a consequence of cost as 
an independent variable (CAIV)-based 
cost-schedule-performance trade-offs during each. 
phase of the acquisition process. 


In the process of refining requirements, key concepts 
that shall be adhered to include: 


keeping all reasonable options open and facilitating 
trade-offs throughout the acquisition process; 


avoiding early commitments to system-specific solutions, 
including those that inhibit future insertion of new 
technology and commercial or non-developmental items; 


132 


133° 


134 


135 


136 


137 


No. . Subject 


PM 


PM 


Both 


Both 


Both 


Both 


Task Object 


update C4iSR 
requirements 


develop performance 
objectives and 
thresholds 
refine requirements 
refine requirements 
refine requirements 
refine requirements 








Modifier Using 

intelligence 

requirements change 

consistent with initial 

statements of 

operational capability 
CAIV-based 
cost-schedule 
-performance 
trade-offs 


keeping all reasonable 
options open 


facilitating trade-offs 


avoiding early 
commitments to 
system specific 
solutions 
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2.3 Requirements 
Evolution 


avoiding early commitments to system-specific solutions, 
including those that inhibit future insertion of new 
technology and commercial or non-developmental items; 


defining requirements in broad operational capability 
terms; and 


using minimum acceptable operational performance 
(thresholds) to establish operational test criteria. 


At each milestone beginning with program initiation 
(usually Milestone |), thresholds and objectives initially 
expressed as measures of effectiveness or 

performance and minimum acceptable requirements for 
the proposed concept or system shall be documented by 
the user or user's representative in an Operational 
Requirements Document (ORD) (see Appendix II). 


Extracted Requirements 


No. 
138 


139 


140 


144 


142 


143 


Subject 
Both 


Both 


Both 


Both 


Both 


User 


Task 
refine 


refine 


refine 


refine 


refine 


document 


Object 
requirements 


requirements 


requirements 


requirements 


requirements 


requirements 


Modifier 


avoiding early 
commitments to 
solutions that inhibit 
future insertion of 
new technology 


avoiding early 
commitments to 
solutions that inhibit 
future insertion of 
commercial items 


avoiding early 
commitments to 
solutions that inhibit 
future insertion of NDI 
items 


in broad operational 
capability terms 


thresholds establish 
operational test criteria 


in terms of MOEs or 
threshold and 
objectives 


Using 


ORD 
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2.3 Requirements 
Evolution 


No. Subject Task 


Thresholds and objectives in the ORD shall be 144 User 
CAIV-based, considering the results of the analysis of 
alternatives and the impact of affordability constraints. 


145 User 


146 User 


Key Performance Parameters (KPPs), validated by the 147 PM 
JROC or cognizant Principal Staff Assistant (PSA), shall 

be included in the appropriate Acquisition Program 

Baseline (APB) (see 3.2.2). A KPP is that capability or 
characteristic so significant that failure to meet the 

threshold can be cause for the concept or system 

selection to be reevaluated or the program to be 

reassessed or terminated. KPPs are extracted from the 

ORD and included in the APB. 


In addition, the user or user’s representative shall work 148 User 
with the Program Manager or other system developer to 

establish, at program initiation, and refine, at subsequent 

milestones, CAIV-based cost and performance 

objectives and critical schedule dates. 


149 User 


document 


document 


document 


document 


establish 


establish 


Extracted Requirements 
Object 


requirements 


requirements 


requirements 


KPPs 


CAIV-based 
objectives 


critical schedule 
dates 


Modifier 


CAIV-based 
requirements 


considering analysis 
of alternatives 


considering 
affordability 
constraints 


KPPs validated 


with PM 


with PM 


Using 
ORD 


ORD 


ORD 


APB 
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2.3.1 Evatuation of In developing system performance requirements, DoD 


Requirements 
Based on 


Components shall evaluate how the desired 
performance requirements could reasonably be modified 


Commercial Market to facilitate the use of potential commercial or 


Potential 


non-developmental items, components, specifications, 
open standards, processes, technology, and sources 
(10 USC 2377 ; CCA). 


Extracted Requirements 


No. 
150 


151 


152 


153 


154 


155 


156 


157 


158 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


Object 
requirements 


requirements 


requirements 


requirements 


requirements 


requirements 


requirements 


requirements 


requirements 


Modifier Using 


for use of commercial 
items 


for use of commercial 
components 


for use of commercial 
specifications 


for use of NDI items 


for use of NDI 
components 


for use of NDI 
specifications 


for use of open 
standards 


for use of open 
processes 


for use of open 
technology 
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2.3.1 Evaluation of In developing system performance requirements, DoD 
Components shall evaluate how the desired 
‘performance requirements could reasonably be modified 
to facilitate the use of potential commercial or 
non-developmental items, components, specifications, 
open standards, processes, technology, and sources 


Requirements 
Based on 
Commercial Market 
Potential 


2.4 Analysis of 
Alternatives 


2.5 Affordability 


(10 USC 2377 ; CCA). 


The results of the evaluation shall be included as part of 


the initial ORD. 


An analysis of alternatives is part of the CAIV process 
and shall be prepared and considered at appropriate 
milestone decision reviews of ACAT | programs, 
beginning with program initiation (usually Milestone 1). 


There shail be a clear linkage between the analysis of 
alternatives, system requirements, and system . 
evaluation measures of effectiveness (CCA and PRA). 


Components shall plan programs consistent with the 
DoD Strategic Plan, and based on realistic projections of 
likely funding available in the Future Years Defense 
Program (FYDP) and in years beyond the FYDP. 


Extracted Requirements 


No. 


159 PM 


160 


161 


162 


163 


164 


User 


PM 


PM 


Both 


Both 


Subject Task 


evaluate 


document 


analyze 


analyze 


plan 


plan 


Object 


requirements 


results of 


evaluation 


project 


project 


project 


project 


Modifier Using 
for use of open 

sources 

evaluation of ORD 


requirements based 
on commercial market 
potential 


analysis of 
alternatives 


consistency among 
analysis of 
alternatives, system 
requirements, and 
MOE's 


DOD Strategic 
Pian 


based on likely funding FYDP 
FYDP and beyond 
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2.5 Affordability 


Affordability shall be assessed at each milestone 
decision point beginning with program initiation (usually 
Milestone 1). 


No acquisition program shalt be approved to proceed 
beyond program initiation unless sufficient resources, 
including manpower, are programmed in the most 


- recently approved FYDP, or will be programmed in the 


2.6 Supportability 


3.2 Program Goals 


next Program Objective Memorandum (POM), Budget 
Estimate Submission (BES), or President's Budget (PB) 
(CCA and OMB Circular A-11 ). 


Support requirements are not to be stated as distinct 
logistics elements, but instead as performance 
requirements that relate to a system’s operational 
effectiveness, operational suitability, and life cycle cost 
reduction (CCA and PRA ). 


Every acquisition program shall establish program goals 
for the minimum number of cost, schedule, and 
performance parameters that describe the program. 


Extracted Requirements 


No. 


166 


167 


168 


169 


170 


171 


172 


Subject 
165 Both 


Both 


’ Both 


Both 


Both 


PM 


PM 


PM 


Task 
assess 


determine 


determine 


determine 


determine 


define 


establish 


establish 


Object 
affordability 


resources 


resources 


resources 


resources 


support 
requirements 


cost goals 


schedule goals 


Modifier Using 

are approved FYDP 

are approved Budget 
Estimate 
Submission 

are approved POM 

are approved President's 
Budget 


in terms of 
performance 
requirements 


to describe program 


to describe program 
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Applicable DoD 5000.2R Statements 


3.2 Program Goals Every acquisition program shall establish program goals 


3.2.1 Objectives 
and Thresholds 


for the minimum number of cost, schedule, and 
performance parameters that describe the program. 


Program goats shall be linked to the DoD Strategic Plan 
and other appropriate subordinate strategic plans, such 


as Component and functional strategic plans, and to the- 


Strategic information Resources Management Plan 
required by the Paperwork Reduction Act of 1995 . 
These program goals shall be identified as objectives 
and thresholds. 


If the threshold values are not otherwise specified, the 
threshold value for performance shall be the same as 
the objective value, the threshold value for schedule 
shall be the objective value plus six months for ACAT | 
and three months for ACAT iA, 


Extracted Requirements 


~ No. 


173 


174 


175 


176 


177 


178 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
establish 


establish 


establish 


establish 


establish 


establish 


Object 


performance goals 


goals 


goals 


goals 


goals 


threshold 


Modifier 
to describe program 


as objectives and 
thresholds so that 
they are linked to 
higher level plans 


as objectives and 
thresholds so that 
they are linked to 
higher level plans 


as objectives and 
thresholds so that 
they are linked to 
higher level plans 


as objectives and 
thresholds so that 
they are linked to 
higher level plans 


same as objective if 
not stated differently 


Using 


DOD Strategic 
Plan , 


Component 
strategic 


functional 
strategic 


Strategic 
Information 
Resources 
Management 
Plan © 
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3.2.1 Objectives 
and Thresholds 


3.2.2 Acquisition 
Program Baselines 


No. 


If the threshold values are not otherwise specified, the 179 
threshold value for performance shall be the same as 

the objective value, the threshold value for schedule 

shall be the objective value plus six months for ACAT | 

and three months for ACAT IA, 


If the threshold values are not otherwise specified,... the 180 
threshold value for cost shall be the objective value plus 
10 percent. 


Trade-offs outside the trade space (i.e., program 181 
parameter changes) may be considered; however, 

trade-offs outside the trade space shall not be made 

without the approval of the MDA and ORD approving authority 


In addition, key performance parameters validated by the 182 
JROC or by a PSA may not be traded-off without JROC 
approval or PSA review. 


Every acquisition program shall establish an Acquisition 183 
Program Baseline (APB) to document the cost, schedule, 

and performance objectives and thresholds of that 

program beginning at program initiation. 


184 


185 


Performance shall include supportability and, as 186 


applicable, environmental requirements. 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
establish 


establish 


obtain 


obtain 


document 


document 
document 


document 


Extracted Requirements 


Object 
threshold schedule 


threshold cost 


approval for 
trade-offs 


approval for 
trade-offs 


cost goals 


schedule goals 


performance goals 


supportability goals 


Modifier 


as objective plus 6 
months (3 mos ACAT 
1A) 


as objective plus 10% 
(unless otherwise 
specified) 


outside of established 
trade space 


outside of JROC 
established trade 
space 


Using 


MDA, ORD 
approving 
authority 


JROC 


APB 


APB 


APB 


APB 
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3.2.2 Acquisition 
Program Baselines 


3.2.2.1 Preparation 
and Approval 


Performance shall include supportability and, as 
applicable, environmental requirements. 


The format for the APB is included in the Consolidated 
Acquisition Reporting System (CARS) (see Appendix I) 


The PM, in coordination with the user, shall prepare the 
APB at program initiation for ACAT | and ACAT IA 
programs, at each subsequent major milestone decision, 
and following a program restructure or an . 
unrecoverable program deviation. 


The Program Executive Officer (PEO) and the 
Component Acquisition Executive (CAE), as appropriate, 
shall concur in the APB. The MDA shall approve the 
APB. 


For ACAT | and ACAT IA programs, the MDA shall not 
approve the APB without the coordination of the Under 

Secretary of Defense (Comptroller) (10 USC 2220(a)(2) 
) and the Joint Requirements Oversight Council (JROC) 


or, in the case of ACAT IA programs, the Principal Staff 


Assistant (PSA) in place of the JROC (where applicable). 


Extracted Requirements 


No. 
187 


188 


189 


082 


191 


192 


Subject 


PM 


PM 


PM 


MDA 


MDA 


MDA 


Task 
document 


document 


prepares 


approve 


coordinate 


with 


coordinate 
with 


Object 


environmental 
goals 


goals 


APB 


APB 


USD (Comptroller) 


JROC 


Modifier 


for the APB 


beginning at initiation 


prior to approval for 
ACAT I/IA 


prior to approval for 
ACAT I/IA 


Using 
APB 


Consolidated 
Acquisition 
Reporting 
System 
(CARS) 


APB 


APB 
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3.2.2.1 Preparation No funds shall be obligated for an ACAT | program after 


and Approval 


3.2.3 Exit Criteria 


3.3 Acquisition 
Strategy 


that program enters engineering and manufacturing 
development or production and deployment until an APB 
has been approved by the MDA, unless the USD(A&T) 
has specifically approved the obligation, in accordance 
with 10 USC 2435(b) . 


MDAs shall use exit criteria to establish goals for ACAT | 
(10 USC 2220(a)(1)) and ACAT IA (CCA ) programs 
during an acquisition phase. The MDA shall approve the 
exit criteria. 


At each milestone review, the PM shall propose exit 
criteria appropriate to the next phase of the program. 


~ 


The exit criteria shall serve as gates that, when 
successfully passed or exited, demonstrate that the 
program is on track to achieve its final program goals 
and should be allowed to continue with additional 
activities within an acquisition phase or be considered 
for continuation into the next acquisition phase. 


Each PM shall develop and document an acquisition 
strategy that shall serve as the roadmap for program 
execution from program initiation through 
post-production support. 


Extracted Requirements 


No. 
193 


194 


195 


196 


197 


A primary goal in developing an acquisition strategy shall 198 


be to minimize the time and cost of satisfying an 
identified, validated need, consistent with common 
sense and sound business practices. 


Subject 


MDA 


MDA 


PM 


Both 


PM 


PM 


Task 
approve 


approve 


propose 


use 


develop 


develop 


Object Modifier 


APB prior to obligation of 
funds for ACAT | EMD, 
production and 


deployment 
project goals 
project goals 
quality gates 
process 
process minimize cost and 
schedule 


Using 


exit criteria 


exit criteria 


exit criteria 


acquisition 
Strategy 


acquisition 
Strategy 











Applicable DoD 5000.2R Statements 


3.3 Acquisition 
Strategy 


The acquisition strategy shall evolve through an iterative 
process and become increasingly more definitive in 
describing the relationship of the essential elements of a 
program. 


Essential elements in this context include, but are not 
limited to, open systems, sources, risk management, 

_ cost as an independent variable, contract approach, 
management approach, environmental considerations, 
and source of support. 


TOT 





Extracted Requirements 


No. 
199 


200 


201 


202 


203 


204 


205 


206 


Subject 


PM 


PM 


“PM 


PM 


PM 


PM 


PM 


PM 


Task 
refine 


document 


document 


document 


document 


document 


document 


document 


Object 
process 


process open 
systems 


process sources 


process risk 
management 


process CAIV 


process contract 
approach 


process 
management 
approach 


process 
environmental 
considerations 


Modifier 


Using 


acquisition 
strategy 


acquisition 
strategy 


acquisition © 
strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 
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3.3 Acquisition 
Strategy 


Essential elements in this context include, but are not 
limited to, open systems, sources, risk management, 
cost as an independent variable, contract approach, 
management approach, environmental considerations, 
and source of support. 


The acquisition strategy shall include the critical events 
that shall govern the management of the program. The 
event-driven acquisition strategy shall explicitly link 
program decisions to demonstrated accomplishments in 
development, testing, initial production, and life cycle 
support. 


The acquisition strategy shall be tailored to meet the 
specific needs of individual programs, including 


. consideration of incremental (block) development and — 


fielding strategies. 


The benefits and risks associated with reducing lead 
time through concurrency shall be specifically 
addressed in tailoring the acquisition strategy. 


Extracted Requirements 


No. 
207 


208 


209 


210 


211 


212 


213 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
document 


document 


taitfor 


consider 


consider 


analyze 


document 


Object 


process source of 
support 


process Critical 
events 


process 


incremental 
development 


fielding strategies 


concurrency 


concurrency 


Modifier 


linked to project 
decisions 


Using 
acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
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| 3.3 Acquisition 
Strategy 


col 


Open Systems 


In tailoring an acquisition strategy, the PM shall address 
the management requirements imposed on the 
contractor(s) (CCA ). 


The PM shall initially develop the acquisition strategy at 
program initiation (usually Milestone 1), 


and shail keep the strategy current by updating it 
whenever there is a change to the approved acquisition 
strategy or as the system approach and program 
elements are better defined. 


The PM shall develop the acquisition strategy in 
coordination with the Working-level Integrated Product 


_ Team. 


The PEO and CAE, as appropriate, shall concur in the 
acquisition strategy. The MDA shall approve the 
acquisition strategy prior to release of the formal 
solicitation. This approval shall usually precede the 
milestone review, except at program initiation when the 
strategy shalt usually be approved as part of the initial 
milestone decision review. — 


PMs shall specify open systems objectives and 
document their approach for measuring the level of 
openness of systems, subsystems, and components to 
be acquired, and devise an open systems strategy to 
achieve these requirements. 
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219 
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PM 
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document 
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approve 
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Object 
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management 
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Modifier 


contractor 
management 
requirements 
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process 
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open systems 
objectives 


Using 
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strategy 


acquisition | 
Strategy | 


acquisition 
strategy 


acquisition 
Strategy 
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Strategy 
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Open Systems 


3.3.2 Sources 


PMs shall specify open systems. objectives and 
document their approach for measuring the level of 
Openness of systems, subsystems, and components to 
be acquired, and devise an open systems eHereey to 
achieve these requirements. 


In developing and updating the acquisition strategy, the 
PM shall consider all prospective sources of supplies 
and/or services that can meet the need, both domestic 
and foreign. 


Commercial and non-developmental items shall be 
considered as the primary source of supply (10 USC 
2377; CCA ). 


Extracted Requirements 


No. 
221 


222 


223 


224 


225 


226 


227 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
develop 


document 


develop 


document 


consider 


consider 


consider 


Object 


open systems 
measurement 
approach 


open systems 
measurement 
approach 


open systems 


strategy 


open systems 
strategy 


sources 


SOUFCeS 


sources 


Modifier 


for systems, 
subsystems and 
components 


for systems, 
subsystems and 
components 


for systems, 
subsystems and 
components 


for systems, 
subsystems and 
components 


all domestic and 
foreign 


primary source 


primary source 


Using 


acquisition 
Strategy 


acquisition 
Strategy — 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 


commercial 
items 


NDI 
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3.3.2 Sources 


The PM, through the use of Integrated Product Teams 
(IPTs), shall include in the consideration the national 
policies on contracting and subcontracting with small 
business (15 USC 644(a) & (j) ), small and 
disadvantaged business (15 USC 637(d)(4)-(6) ), 
women-owned small business (PL 100-533 ), and labor 
surplus areas (15 USC 644(d) ). 


Alternatives considered to secure participation of these 
entities as prime contractors in the initial or later phases 
of the life cycle shall be addressed. 


Extracted Requirements 
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PM 
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PM 
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consider 


consider 


develop 


develop 


develop 


develop 
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sources 


sources 


sources 


sources 


strategy 


strategy 


Strategy 
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Modifier 
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IAW national policies 
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as prime contractor 
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Using 
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d business 
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No. Subject Task Object Modifier Using 
3.3.2 Sources In addition, strategies to ensure participation at the 236 PM develop strategy as subcontractors small 
subcontract levels shall be developed. business 
237 PM develop strategy as subcontractors disadvantage 
d business 
238 PM develop strategy as subcontractors = women-owne 
d business 
239 PM develop strategy as subcontractors labor surplus 
areas 
3.3.2.1 Commercial Market research and analysis shall be conducted to - 240 PM determine availability and of commercial items market 
and determine the availability and suitability of existing suitability research 
Non-Developmental commercial and non-developmental items prior to the 
Items commencement of a development effort, during the 
development effort, and prior to the preparation of any 
- product description. 
241 PM determine _ availability and of NDI market 
Suitability research 
242 PM determine availability and of commercial items market 
suitability research 
243 PM determine availability and of NDI market 


suitability research 
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3.3.2.1 Commercial Market research and analysis shall be conducted to 


and determine the availability and suitability of existing 
Non-Developmental commercial and non-developmental items prior to the 
Items commencement of a development effort, during the 


development effort, and prior to the preparation of any 
product description. 


The PM shall define requirements (including hardware, 
software, standards, data, and automatic test systems) 
in terms that enable and encourage offerors to supply 
commercial and non-developmental items... 
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Using 
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specs 
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Extracted Requirements 


No. Subject Task Object Modifier Using 
3.3.2.1 Commercial The PM shall define requirements (including hardware, 252 PM define requirements in terms that automatic test 
and software, standards, data, and automatic test systems) encourage commercial systems 
Non-Developmental in terms that enable and encourage offerors to supply items specs 
Items commercial and non-developmental items.... 
253 PM define requirements in terms that hardware 
encourage NDI specs 
254 PM define requirements in terms that software 
encourage NDI specs 
255 PM define requirements in terms that standards 
encourage NDI 
256 PM define requirements in terms that data specs 
encourage NDI 
257 PM define requirements in terms that automatic test 
: encourage NDI systems 
specs 
The PM shall require prime contractors and 258 PM require commercial items from prime contractors contract 
subcontractors at all levels to incorporate commercial 
and non-developmental items as components of items 
supplied 
259 PM require NDI from prime contractors contract 
260 PM require commercial items from subcontractors contract 
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3.3.2.1 Commercial! 
and 
Non-Developmental 
items 


The PM shail require prime contractors and 
subcontractors at all levels to incorporate commercial! 
and non-developmental items as components of items 
supplied 


and shall modify requirements to the maximum extent 
practicable, to ensure that the requirements can be met 
by commercial and non-developmental items (10 USC 
2377 ). 


Commercial and non-developmental items selected shall 
be based on open standards and commercial item 
descriptions to the maximum extent practicable. 


If products with closed interfaces are to be acquired, 
risks and impacts on total cost of ownership shall be 
evaluated. 


Extracted Requirements 
Subject Task 


No. 
261 


262 


263 


264 


265 


266 


267 


268 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


require 


define 


define 


select 


select 


select 


select 


evaluate 


Object 
NDI 


requirements 


requirements 


commercial items 


commercial items 


NDI 


NDI. 


risk © 


Modifier Using 
from subcontractors contract 


to be met by specs 
commercial items 


to be met by NDI specs 


based on open 
standards 


based on commercial 
item descriptions 


based on open 
standards 


based on commercial 
item descriptions 


of using closed 
interfaces 


Ol 


Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
3.3.2.1 Commercial If products with closed interfaces are to be acquired, 269 PM evaluate impact on total cost of using closed 
and risks and impacts on total cost of ownership shall be of ownership interfaces 
Non-Developmental evaluated. 
items 
Preference shall be given to the use of commercial items 270 PM use commercial items before NDI! 
first and non-developmental items second. 
Use of commercial or non-developmental items does not 271 PM consider environmental when using 
exempt the PM from complying with environmental ‘ requirements commercial or NDI 
requirements, unless exempted.by statute. items 
3.3.2.2 DualUse The PM shall develop an acquisition strategy that 272 PM encourage dual use acquisition 
Technologies and encourages offerors to employ dual use technologies or technologies strategy 
Use of Commercial commercial plants and supplies for defense-unique . 
Plants items, to the maximum extent practicable. 
273 PM encourage commercial plants acquisition 
and supplies Strategy 
Market research and analysis shall be conducted to 274 PM identify dual use market 
identify and evaluate possible dual use technologies and technologies research 
commercial suppliers throughout research and 
development. 
275 PM evaluate dual use market 
technologies analysis 
276 PM identify commercial "market 


suppliers research 
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Applicable DoD 5000.2R Statements 


3.3.2.2 Dual Use 
Technologies and 
Use of Commercial 
Plants 


3.3.2.3 Industrial 
Capability 


Market research and analysis shall be conducted to 
identify and evaluate possible dual use technologies and 
commercial suppliers throughout research and 
development. 


Contractors shall also be encouraged to integrate military 
production into commercial production to the maximum 
extent possible. 


Finally, system design shall facilitate the incorporation 
and insertion of leading edge dual use technologies and 
commercial suppliers through the system's life cycle. 


The PM shall structure the acquisition strategy to 
promote sufficient program stability to encourage 
industry to invest, plan and bear risks. 


Programs shal! minimize the need for new 
defense-unique industrial capabilities. 


Foreign sources and international cooperative 
developments shall be used where advantageous and 
within limitations of the law (DFARS Part 225 ). 
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277 


278 


279 


280 


281 


282 


283 


284 
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PM 


PM 


PM 


PM 


PM 


PM 


PM 


Subject Task 


evaluate 
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develop 


develop 


plan 


use 


consider 


consider 


Object Modifier 


commercial 
suppliers 


integration of 


military and 

comntercial 

production 

system allow insertion of 
leading edge dual use 
technologies 

system allow insertion of 


commercial suppliers 


program stability sufficiently to 
encourage industry to 
bear risks 


industrial that are non-unique 
capabilities 


foreign sources 


* 


cooperative 
developments 


Using 
market 
analysis 


contract 


specs 


specs 


acquisition 
strategy 


CII 


Applicable DoD 5000.2R Statements 


3.3.2.3 Industrial 


Capability 


The program acquisition strategy shall analyze the 
industrial capability to design, develop, produce, support 
and, if appropriate, restart the program (10 USC 2440 ). 


This analysis shall identify DoD investments needed to 
create new industrial capabilities, and the risks of 
industry being unable to provide program design or 
manufacturing capabilities at planned cost and schedule. 


If the analysis indicates there is an issue beyond the 
scope of the program, the PM shall raise it through the 
PEO to the MDA. 
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289 


290 


291 


292 
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PM 


PM 


PM 


PM 


PM 


Task 
analyze 


analyze 


analyze 


analyze 


analyze 


identify 


analyze 


report 


Object 


industrial 
capabilities 


industrial 
capabilities 


industrial 
capabilities 


industrial 
capabilities 


industrial 
capabilities 


industrial 
capabilities 


industrial 
capabilities 


industrial 
capabilities 


Modifier 
to design 


to develop 


to produce 


to support 


to restart the program 


that are new 


risks of inadequate 
capability 


issues to MDA 


Using 


acquisition 
Strategy 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
Strategy 


acquisition 
Strategy 


acquisition 
strategy 


acquisition 
strategy 
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Applicable DoD 5000.2R Statements 


3.3.2.3 Industrial 
Capability 


Critical Product and 
Technology 
Competition 


Prior to production termination, Components shall take 
actions to ensure there will be adequate industrial 
capabilities and capacity to meet post-production 
operational needs. Actions shall address product 
technology obsolescence, replacement of life limited 
items, and regeneration options for unique 
manufacturing processes. 


All acquisition programs shall foster competition at 
subcontractors levels, as well as at the prime level, 
particularly in critical product and technology areas. 


To accomplish this, the PM shall focus on critical product 
and technology competition when: a) formulating the 
acquisition strategy; b) exchanging information with 


industry; and c) managing the program system 


engineering and life cycle. 


The acquisition strategy shall be based, in part, on an 
analysis of product and technology areas critical to 
meeting the program's needs. 


Extracted Requirements 


No. 
293 


294 


295 


296 


296 


298 


299 
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PM 
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PM 


PM 


PM 


PM 


Subject Task 


plan 


plan 
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use 


use 


analyze 


analyze 


Object 


industrial 
capabilities 


industrial 
capabilities 


industrial 
capabilities 


competition 


competition 


critical product 
areas 


critical technology 
areas 


Modifier 


to handle product 
technology 
obsolescence 


to handle replacement 
of life limited items 


to handle regeneration 
options for unique 
manufacturing 
processes 


Using 


acquisition 
strategy 


acquisition 
Strategy 


acquisition 
strategy 


acquisition 
strategy 
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Applicable DoD 5000.2R Statements 


Critical Product and The acquisition strategy shall identify the potential 


Technology 
Competition 


industry sources available to supply these critical 
products and technologies. 


The acquisition strategy shall highlight areas of potential 
vertical integration, that is, areas where potential prime 
contractors are also potential suppliers for critical 
products and technologies. 


The acquisition strategy shall describe the approaches 
the PM will use (e.g., requiring an open systems 
architecture, investing in alternate technology or product 
solutions, breaking out a subsystem or component, etc.) 
to establish or maintain access to competitive suppliers 
for critical areas at the system, subsystem, and 
component levels. - 


During early exchanges of information with industry 
(e.g., the draft RFP process), PMs shall identify those 
critical product and technology areas that the primes 
plan to provide internally or through exclusive teaming, 
and assess possible competition effects of these 
choices. , 
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No. 
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304 


305 
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PM 


PM 


PM 


PM 
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identify 
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describe 
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Object Modifier 
sources 


vertical integration 


approaches requiring open 
systems architecture 


approaches investing in alternate 
technology 

approaches breaking out 
subsystem or 
component 

critical product prime plans to provide 

areas internally 


a 


critical technology prime plans to provide 
areas internally 


Using 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
Strategy 


acquisition 
strategy 


acquisition 
strategy 
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Applicable DoD 5000.2R Statements 


No. 
Critical Product and During early exchanges of information with industry 307 
Technology (e.g., the draft RFP process), PMs shall identify those 
Competition critical product and technology areas that the primes 
plan to provide internally or through exclusive teaming, 
- and assess possible competition effects of these 
choices. 
308 
309 


The PM shall take action to mitigate areas of risk. When 310 
those actions require a change to the approved 

acquisition strategy, the PM shall recommend the needed 
change to the MDA. 


As the designs evolve, the PM shall continue to analyze 311 


~ how the prime contractor is addressing the program’s 


critical product and technology areas. 


312 


Contractors shall be challenged during requirements and 313 
design reviews to support why planned materiel 

solutions for subsystem and component requirements 

critical to the program are appropriate when other 

choices are available. This monitoring shall continue 

through the weapon system life cycle (e.g., 

reprocurements, logistics support). 
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PM 
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analyze 


analyze 
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critical product 
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critical technology 
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effects 


risk 


critical product 
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critical technology 
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justification 
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prime plans to provide 


through exclusive 
teaming 


prime plans to provide 


through exclusive 
teaming 


of prime choices 


being addressed by 


the prime 


being addressed by 


the prime 


for materiel solutions 
provided by contractor 


Using 


acquisition 
strategy 


reviews 


OTT 


Applicable DoD 5000.2R Statements 


3.3.2.5 Leasing 


3.3.3 Cost, 
Schedule, and 
Performance Risk 
Management 


The PM shall consider the use of leasing in the 
acquisition of commercial vehicles and equipment 
whenever the PM determines that leasing of such 
vehicles is practicable and efficient. 


The PM shail not enter into any lease with a term of 18 
months or more, or extend or renew any lease for a 

term of 18 months or more, for any vessel, aircraft, or 
vehicle, unless the PM has considered all costs of such 
a lease (including estimated termination liability) and has 
determined in writing that the lease is in the best interest 
of the Government. (10 USC 2401a ) . 


The PM shall establish a risk management program for 
each acquisition program to identify and control 
performance, cost, and schedule risks. 


The risk management program shall identify and track 
risk drivers, define risk abatement plans, and provide for 
continuous risk assessment throughout each acquisition 
phase to determine how risks have changed. 
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318 


319 


320 


Subject 


PM 


PM 


PM 


-PM 


PM 


PM 


PM 


Task 
consider 


consider 


document 
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track 
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Object 
leasing 


all costs 


all costs 
risk management 


program 


risk drivers 


risk drivers 


risk abatement 
plans 


Modifier Using 
commercial items 


of leases greater than 
18 months 


of leases greater than 
18 months 


risk 
management 
program 


risk 
management 
program 


risk 
management 
program 


risk 
management 
program 
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Applicable DoD 5000.2R Statements 


3.3.3 Cost, 
Schedule, and 
Performance Risk 
Management 


3.3.4 Cost as an 
Independent 
Variable (CAIV) 


The risk management program shall identify and track 
risk drivers, define risk abatement pians, and provide for 
continuous risk assessment throughout each acquisition 
phase to determine how risks have changed. 


Risk reduction measures shall be included in 
cost-performance trade-offs, where applicable. 


The risk management program shall plan for back-ups in 
risk areas and identify design requirements where 
performance increase is small relative to cost, schedule, 
and performance risk. 


The acquisition strategy shall include identification of the 
risk areas of the program and a discussion of how the 
PM intends to manage those risks. 


The CAIV process shall be used to develop an 
acquisition strategy for acquiring and operating 
affordable DoD systems by setting aggressive, 
achievable cost objectives and managing achievement 
of these objectives. 


Extracted Requirements 
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321 PM 
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323 
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325 
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327 


328 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


plan 


analyze 


plan 


identify 


identify 


plan 


use 


manage 


Object Modifier 


continuous risk 
assessment 


risk reduction 
measures 


back-ups 


risk drivers 


risk areas 


risk management 


program 

CAIV setting aggressive, 
achievable cost 
abjectives 

CAIV objective achievement 


Using 

risk 
management 
program 


cost-performa 
nce trade-offs 


risk 
management 
program 


risk 
management 
program 


acquisition 
strategy 


acquisition 
strategy 


acquisition 
strategy 
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Applicable DoD 5000.2R Statements 


3.3.4 Cost as an 
Independent 
Variable (CAIV) 


3.3.4.1 
Cost/Performance 
Tradeoffs 


Cost objectives shall also be set to balance mission 
needs with projected out-year resources, taking into 
account anticipated process improvements in both DoD 


_ and defense industries (GPRA and CCA ). 


Cost reductions shall be accomplished through 
cost/performance tradeoff analyses, which shall be 
conducted before an acquisition approach is finalized. 


Upon approval of a MNS (see 2.3), a CAIV strategy shall 
be formulated as part of the acquisition strategy to set 
cost objectives. 


By program initiation (usually Milestone 1), each ACAT | 
and ACAT IA PM shall have established life cycle cost 


_ objectives for the program through consideration of 


projected out-year resources, recent unit costs, 
parametric estimates, mission effectiveness analysis 
and trades, technology trends, and other relevant 
considerations such as commercial versus DoD 
specifications (see 3.3.5.2) and the open systems 
strategy and design (see 3.3.1 and 4.3.4). 
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CAIV 


CAIV 
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objectives 


projected out-year 
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recent unit costs 


parametric 
estimates 


Modifier Using 


to balance mission 
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resources 


taking into account’ 
process improvements 
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strategy 


life cycle cost 
objectives 


life cycle cost 
objectives 


life cycle cost 
objectives 
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Applicable DoD 5000.2R Statements 


3.3.4.1 By program initiation (usually Milestone |), each ACAT | 
Cost/Performance and ACAT IA PM shall have established life cycle cost 
Tradeoffs objectives for the program through consideration of 


projected out-year resources, recent unit costs, 
parametric estimates, mission effectiveness analysis 
and trades, technology trends, and other relevant 
considerations such as commercial versus DoD 
specifications (see 3.3.5.2) and the open systems 
strategy and design (see 3.3.1 and 4.3.4). 


A complete set of life cycle cost objectives shall include 
RDT&E, production, MILCON, operating and support, and 
disposal costs. 


Extracted Requirements 
Subject Task 


No. 
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consider 


consider 


consider 


consider 


consider 


Object Modifier 
mission 

effectiveness 

analysis and 


technology trends 
commercial vs DOD 


specs 


open systems 
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RDT&E costs 


production costs 
MILCON costs 


operating costs 


Using 


life cycle cost 
objectives 


life cycle cost 
objectives 


life cycle cost 
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life cycle cost 
objectives 


life cycle cost 
objectives 


life cycle cost 
objectives 


life cycle cost 
objectives 


life cycle cost 
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Applicable DoD 5000.2R Statements - Extracted Requirements 


No. Subject Task Object Modifier Using 
3.3.4.1 A complete set of life cycle cost objectives shall include 344 PM consider support costs life cycle cost 
Cost/Performance RDT&E, production, MILCON, operating and support, and objectives 
Tradeoffs disposal costs. 
345 PM consider disposal costs life cycle cost 
objectives 
At each subsequent milestone review, cost objectives 346 Both assess cost objectives 
and progress towards achieving them shall be 
reassessed. 
347 Both assess cost objectives 
performance 
the number of threshold items in requirements 348 User document requirements limited in number ORD 
documents and acquisition program baselines shall be : 
strictly limited, the threshold values shall represent true 
minimums, and requirements shall be stated in terms of 
capabilities, rather than technical solutions and 
specifications. 
349 Both document requirements limited in number APB 
350 User establish requirements thresholds that are 


true minimums 


351 All document requirements as capabilities vs 
technical solutions 
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Applicable DoD 5000.2R Statements 


3.3.4.1 
Cost/Performance 
Tradeoffs 


RFPs shall include a strict minimum number of critical 
performance criteria that allow industry maximum 
flexibility to meet overall program objectives. 


Cost objectives shall be used as a management tool. 


The source selection criteria communicated to industry 
shall reflect the importance of developing a system that 
can achieve stated production and life cycle cost 
objectives. 


The CPIPT (normally led by the PM or the PM’s 
representative) shall be empowered to recommend to 
the PM performance or engineering and design changes 
as long as the threshold values in the Operational | 
Requirements Document (ORD) and APB can be 
achieved. If the changes require ORD/APB threshold 
value changes, the leader of the CPIPT shall notify the 
PM and the OIPT leader. 





Extracted Requirements 


No. 
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355 


356 


Subject 


PM 


PM 


PM 


PM 


PM 


The PM shall ensure that proposed changes are quickly 357 PM 


brought before the ORD and/or APB approval authorities 
for decision. 


The PM shall have responsibility for the conduct and 
integration of all cost performance trade-off analyses 
conducted. 


358 


PM 


Task 
document 


use 


establish 


establish 


use 


report 


conduct 


Object 
requirements 


CAIV 


source selection 
criteria 


source selection 
criteria 


CPIPT 


requirements 
changes 


cost performance 





Modifier Using 


minimize number of RFP 
criteria 


to achieve production 
objectives 


to achieve life cycle 
cost objectives 


in specified way 


quickly 


trade-off 
analyses 
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Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
3.3.4.2 Cost RFPs shall be structured to incentivize the contractor to 359 PM structure incentives to meet or exceed RFP 
Management meet or exceed cost objectives. cost objectives 
Incentives 

Whenever applicable, risk reduction through use of 360 PM use risk reduction contractor uses RFP 
mature processes shall be a significant factor in source measures mature processes 
selection. 
Therefore, competition shall be maintained for as longas 296 PM use competition acquisition 
practicable in all acquisition programs. strategy 
Incentives shall be applied to both Government and 362 PM use incentives for CAIV RFP 
industry to achieve the objectives of cost as an 
independent variable. 

363 PM use incentives for CAIV Gov't SOW's 
Awards programs (both monetary and non-monetary) 364 PM use awards, monetary _ for CAIV 
and “shared savings” programs shail be used creatively 
to encourage the generation of cost-saving ideas for all 
phases of life cycle costs. 

365 PM use awards, for CAIV 


° non-monetary 


366 PM use shared savings for CAIV 


Incentive programs shall target both individuals and 367 PM use incentives for industry individuals 
teams in both government and industry. 
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Applicable DoD 5000.2R Statements 


3.3.4.2 Cost 
Management 
incentives 


3.3.5 Contract 
Approach 


Incentive programs shall target both individuals and 
teams in both government and industry. 


Incentives shall stress up-front investments to minimize 
production and/or operation and: support costs, where 
applicable. 


The acquisition strategy shall discuss the types of 
contracts contemplated for each succeeding phase, 
including considerations of risk assessment, reasonable 
risk-sharing by Government and contractor(s), and the 
incentive structure for contractors to decrease cost 
(CCA ). 


The strategy shall specify if options are to be used for 
future requirements. 
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strategy 
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Applicable DoD 5000.2R Statements 


No. 
3.3.5 Contract Fixed price development contracts of $25 million or more 376 
Approach or fixed price type contracts for lead ships shall not be 
used without the prior approval of the USD(A&T) 
(DFARS 235.006 ). 
Multiyear contracting shall be considered for full rate . 377 


production and implemented when the requirements of 
FAR 17.1 are satisfied. 


Multiyear contracting shall be done in accordance with 378 
10 USC 2306b . ; 


To the maximum extent practicable, modular contracting, 379° 


as described in Section 5202 of Division E of the 
Clinger-Cohen Act , shall be used for major information 


technology acquisitions. 

3.3.5.1 Competition PMs and contracting officers shall provide for full and 380 
open competition, unless one of the limited statutory 
exceptions apply (FAR 6.3 ). 
PMs and contracting officers shall use competitive 381 


procedures best suited to the circumstances of the 
acquisition program. 


The acquisition strategy for all acquisition programs shall 382 
describe plans to attain program goals via competition in 
all increments and life cycle phases. 


Competitive prototyping, competitive alternative sources, 383 
and competition with other systems that may be able to 
accomplish the mission shall be used where practicable. 
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PM 
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plan 
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Applicable DoD 5000.2R Statements 


3.3.5.1 Competition Competitive prototyping, competitive alternative sources, 


and competition with other systems that may be able to 
accomplish the mission shall be used where practicable. 


The PM shall consider component breakout. 


The acquisition strategy shall address component 
breakout plans and shall include rationale justifying the 
component breakout strategy (DFARS Appendix D ). 


Component breakout shall be considered on every 


program and shall be done when there are significant 
cost savings (inclusive of Government administrative 
costs), when the technical or schedule risk of furnishing 
government items to the prime contractor is 
manageable, and when there are no other overriding 
Governmental interests (e.g., industrial capability 
considerations or dependence on contractor logistics 
support). ; 
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Modifier Using 
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strategy 
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Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 

3.3.5.1 Competition Component breakout shall be considered on every 391 PM use component when there are no 

program and shall be done when there are significant breakout overriding Gov't 

cost savings (inclusive of Government administrative interests 

costs), when the technical or schedule risk of furnishing 

government items to the prime contractor is 

manageabie, and when there are no other overriding 

Governmental interests (e.g., industrial capability 

considerations or dependence on contractor logistics 

support). 


Components considered for breakout shall be listed, and 392 PM analyze component detailed 

a brief rationale (based on supporting analyses from a breakout component 
detailed component breakout review (which shall not be : breakout 
provided to the MDA unless specifically requested)) for review 
those major components where a decision was made 

not to breakout shall be provided. A decision not to 

break out any components shall also require justification. 


3.3.5.2 Best PMs shall avoid imposing government-unique 393 PM analyze requirements for industry 
Practices requirements that significantly increase industry compliance costs 
compliance costs. 


The use of best practices shall be addressed at each 394 Both review best practices 
milestone review. 


3.3.5.3 Cost When applicable, the contract shall require that any 395 PM require earned value compliance Appendix VI, 

Performance system used by the contractor in planning and DOD 5000.2R 
controlling the performance of the contract shall meet 
the criteria set forth in Appendix VI.(earned value) 


The government shall not require the contractor's 396 PM use contractor internal if they comply Appendix Vi, 
internal systems to be changed peMdee they satisfy systems DOD 5000.2R 
these criteria. 
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Applicable DoD 5000.2R Statements 


3.3.5.3 Cost 
Performance 


3.3.5.3.1 
Integrated Baseline 
Reviews 


3.3.5.4 Advance 
Procurement 


Unless waived by the MDA or a designated 
representative, compliance with the EVMS criteria shall 
be required on significant contracts and subcontracts 
within all acquisition programs, including highly sensitive 
classified programs and major construction programs. 


On contracts that are determined to be not significant 
enough for EVMS criteria applicability, the cost/schedule 
status report (C/SSR) (see 6.4.3) shall be required 
unless excluded in accordance with the following 


_ paragraph. 


Compliance with the EVMS criteria shall not be required 
on firm fixed price contracts (including firm fixed price 
contracts with economic price adjustment provisions), 
time and materials contracts, and contracts which’ 
consist mostly of level-of-effort work. Exceptions may 
be made by the MDA for individual contracts. 


For contracts requiring compliance with DoD EVMS 
criteria (see 3.3.5.3) or Cost/Schedule Status Report 
(C/SSR) requirements (see 6.4.3), program managers 
and their technical staffs or Integrated Product Teams 
(IPTs) shall review contractor planning baselines within 
six months after contract award. ; 


In accordance with DoD 7000.14-R , procurement of end 
items shall be fully funded, i.e., the cost of the end items 
to be bought in any fiscal year shall be completely 
included in that year’s budget request. 


Extracted Requirements 
Subject Task 


No. 
397 


398 


399 


400 


401 


402 


PM 


PM 


PM 


PM 


PM 


PM 
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require 
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Object 
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Applicable DoD 5000.2R Statements Extracted Requirements 
No. Subject Task 


3.3.5.4 Advance  (mult-year funding to maintain critical skills...) this 403 PM 
Procurement acquisition technique shall be used only when the cost 

benefits are significant and only with approval of the 

MDA. 


Exit criteria for awarding of the initial long lead-time items 404 Both 
contract and/or for awarding of individual follow-on 

long lead-time lots shail be established as an integral part 

of the milestone approval process. 


These approved exit criteria shall be satisfied before 405 PM 
any advance procurement funding may be released. 


The initiation of advance procurement in support of long 406 PM 
lead material shall use a separate contract. | 


3.3.5.5 Continuous Beginning in FY97, all new contracts shall require on-line 407 PM 


Acquisition and access to, or delivery of, their programmatic and 

Life Cycle Support _ technical data in digital form, unless analysis shows that 
(CALS) life cycle time or life cycle costs would be increased by 
--Acquisition doing so. 


Program Integrated 
Digital Environment 
(IDE) 


408 PM 


409 PM 


analyze 


establish 


accomplish 


fund 


analyze 


analyze 


require 


Object Modifier Using 
multiyear funding 


initial long lead-time exit criteria for award 
items 


exit criteria prior to release of | 

advance procurement 

funds 
initial long lead-time for advanced separate 
items procurement contract 
life cycle costs of required online 

access 


life cycle schedule of required online 
access 


online access of contracts 
contractor data 
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Applicable DoD 5000.2R Statements 


No. 
3.3.5.5 Continuous Preference shall be given to on-line access to contractor 410 
Acquisition and developed data through contractor information services 
Life Cycle Support or existing information technology infrastructure rather 
(CALS) than data delivery. 
--Acquisition 


Program Integrated 
Digital Environment 
(IDE) 


The PM shall be responsible for establishing a data 411 
management system and appropriate IDE that meets the 

data requirements of the program throughout its total 

life cycle. 


412 


MDAs shail assess the IDE developed to enhance the 413 
program and mitigate long-term costs at each milestone 
* and program review. 


Acquisition strategies and plans shall describe the 414 
extent of implementation of these requirements in 
accordance with DFARS 207.105 . 


415 


Solicitations shall require specific proposals for an IDE to 416 
support systems engineering and logistics activities. 


Subject Task 


PM 


PM 


PM 


MDA 


PM 


PM 


PM 


use 


establish 


establish 


assess 


plan 


plan 


require 


Extracted Requirements 


Object Modifier 


existing information 
technology 
infrastructure 


data management meeting total life cycle 
system - program requirements 


IDE meeting total life cycle 
program requirements 


IDE 


data management 
system 


IDE 


IDE proposal to support systems 
engineering 


Using 


acquisition 
Strategy 


acquisition 
strategy 


proposal 


OCI 


Applicable DoD 5000.2R Statements Extracted Requirements 





No. Subject Task Object Modifier Using 
3.3.5.5 Continuous Solicitations shall require specific proposals for an IDE to 417 PM require IDE proposal to support logistics proposal! 
Acquisition and support systems engineering and logistics activities. activities 
Life Cycle Support 
(CALS) 
--Acquisition 
Program Integrated 
Digital Environment 
(IDE) 
The PM shall ensure compatibility of data deliverables 418 PM use existing information for data deliverables 
with existing internal information systems, and augment ‘technology 
such systems as required to provide timely data access infrastructure 
. and distribution consistent with DFARS 227 and 252. 
419 PM provide timely data access consistent with existing 
: DFARS 227 and 252 __ information 
technology 
infrastructure 
420 PM provide data distribution consistent with existing 
DFARS 227 and 252 information 
technology 
infrastructure 
Programs electing not to use the datamanagement ~ 421 PM comply Public Law 104-13 
processes described in DOD 5010.12-M must find other 
ways to comply with Public Law 104-13, The rapemol 
Reduction Act of 1995 (PRA ). 
3.3.6 Management The acquisition strategy shall be developed in sufficient’ 422 PM establish managerial acquisition 
Approach detail to establish the managerial approach that shall be . approach strategy 


used to achieve program goals. 





Tel 








Applicable DoD 5000.2R Statements 


3.3.6.1 
Streamlining 


The PM shall streamline all acquisitions so that the 
acquisitions contain only those requirements that are 
essential and cost-effective. 


Contract requirements shall be stated in terms of 
performance rather than design-specific procedures. 


Management data requirements shail be limited to those 
essential for effective contro!. 


Acquisition process requirements shall be tailored to 
meet the specific needs of individual programs. 


Relief or exemption shall be sought for those 
requirements that fail to add value, are not essential, or 
are not cost-effective. 


Early industry involvement in the acquisition effort, 
consistent with the Federal Advisory Committee Act 
(FACA ), shall be encouraged to take advantage of. 
industry expertise to improve the acquisition strategy. 


Extracted Requirements 


No. Subject Task Object 

423 PM analyze requirements 
424 PM analyze requirements 
425 PM describe requirements 
426 .PM analyze data requirements 
427 PM tailor acquisition 

428 PM analyze requirements 
429 PM analyze requirements 
430 PM involve industry 


431 PM involve industry 


Modifier 
for essentiainess 


for cost-effectiveness 


in performance terms 


for essentialness 


for essentiainess 


for cost-effectiveness 


IAW FACA 


Using 
acquisition 
Strategy 


acquisition 
strategy 


RFP 


acquisition 
Strategy 


Applicable DoD 5000.2R Statements Extracted Requirements 


cel 


No. Subject Task Object Modifier Using 
3.3.6.2 The acquisition strategy shall discuss the potential for 432 PM analyze reciprocal defense consistent with strong acquisition 
International enhancing reciprocal defense trade and cooperation, trade and tech and industrial strategy 
Considerations including international cooperative research, cooperation base 

development, production, logistic support, and the sale 
of military equipment, consistent with the maintenance of 
a strong national technology and industrial base, and 
mobilization capability. 

433 PM analyze international consistent with strong acquisition 
cooperative tech and industrial strategy 
research base 

434 PM analyze international consistent with strong acquisition 
cooperative tech and industrial strategy 
development base 

435 PM analyze international consistent with strong acquisition 

cooperative tech and industrial strategy 
production base 

436 PM analyze international consistent with strong acquisition 
cooperative logistic tech and industrial strategy 
support base 

437 PM analyze international consistent with strong acquisition 
cooperative sale of — tech and industrial strategy 
military equipment base 

This discussion shall meet the requirements specified for 438 PM analyze reciprocal defense {AW 10 USC 2350a(q) 


the cooperative opportunities reported directed by 10 


USC 2350a(q) . 


trade and 
cooperation 





cel 


Applicable DoD 5000.2R Statements 


3.3.6.2 
International 
Considerations 


3.3.6.3 Joint 
Program 
Management 


lf foreign competition is restricted for industrial base 
reasons, USD(A&T) prior approval is required. 


Prior to entering into a cooperative agreement, the 
program shall be reviewed by the MDA and be approved 
as an international program. 


The USD(A&T) shall approve any foreign military sale, 
commitment to sell, or DoD agreement for licensing the 
export of any ACAT | or Il system that has not 
successfully completed the Operational Test and 
Evaluation (OT&E) required prior to approval for full rate 
U.S. production. 


Extracted Requirements 


No. 
439 


440 


441 


© 442 


Joint programs shall be consolidated and collocated at 
the location of the lead Component’s program office, to 
the maximum extent practicable. 


The relationship between the designated organization 
and the Military Departments and Defense Agencies, and 
their respective responsibilities, shall be specified in a 
Memorandum of Agreement (MOA). 


443 


444 


445 


Subject 


PM 


MDA 


PM 


PM 


PM 


PM 


PM 


Task 
obtain 


approve 


obtain 


obtain 


obtain 


locate 


establish 


Object 


USD(A&T) 
approval 


reciprocal defense 
trade and 
cooperation 


USD(A&T) 
approval 


USD(A&T) 
approval 


USD(A&T) 
approval 


office 


MOA's 





Modifier Using 


for restrictions on 
foreign competition 


as an international 
program 


for foreign military sale 


commitment to sell 


agreement for 
licensing export 


at lead component Joint program 
program office 


with other services in Joint program 
joint program 


vel 


Applicable DoD 5000.2R Statements 


3.3.6.3 Joint 
Program 
Management 


Mission needs, operational requirements, and program 
Strategies shall be structured to encourage and to 
provide an opportunity for multi-Component participation. 


The decision to establish a joint program shall be made 
by the MDA, who shall designate the lead Component as 
early in the acquisition process as possible. 


The selected joint program manager is fully responsible 
and accountable for the cost, schedule, and 
performance of the system development. 


A designated joint program shall have one quality . 
assurance program, one program change control 
program, one integrated test program, and one set of 
documentation and reports to include one joint program 
ORD, one Test and Evaluation Master Plan (TEMP), one 
APB, one DAES, one Quarterly Report for ACAT IA 
programs, and one Selected Acquisition Report (SAR) 
for ACAT | programs. 


Extracted Requirements 


No. 
446 


447 


448 


449 


450 


451 


452 


453 


Subject 
User 


User’ 


PM 


- MDA 


PM 


PM 


PM 


PM 


Task 
encourage 


encourage 


encourage 


establish 


account for 


account for 


account for 


establish 


Object Modifier 
Joint program 


Joint program 


Joint program 


Joint program 


cost performance 


schedule 
performance 


technical 
performance 


quality assurance one each 
program 


Using 
MNS 


ORD 


acquisition 
strategy 


Joint program 


Joint program 


Joint program 


Joint program 





cel 


Applicable DoD 5000.2R Statements 


3.3.6.3 Joint 


Program 


_. Management 


A designated joint program shall have one quality 
assurance program, one program change control | 
program, one integrated test program, and one set of 
documentation and reports to include one joint program 
ORD, one Test and Evaluation Master Plan (TEMP), one 
APB, one DAES, one Quarterly Report for ACAT JA 
programs, and one Selected Acquisition Report (SAR) 
for ACAT | programs. 


Extracted Requirements 


No. 
454 


455 


456 


457 


458 


459 


460 


461 


462 


PM 


PM 


PM 


PM _ 


PM 


PM 


PM 


PM 


PM 


Subject Task 


establish 


establish 


establish 


establish 


establish 


establish 


establish 


establish 


establish 


Object 


program change 
control program 


integrated test 
program 


set of 
documentation 


ORD 


TEMP 


APB 


DAES 


Quarterly Report 


SAR 


Modifier 
one each 


one each 


one each 


one each 


one each 


one each 


one each 


one each 


one each 





Using 
Joint program 


Joint program 
Joint program 


Joint program 
Joint program 
Joint program 
Joint program 
Joint program 


Joint program 


9¢1 


Applicable DoD 5000.2R Statements 


3.3.6.5 Technical 
Representatives at 
Contractor 
Facilities 


PMs shall make maximum use of Defense Contract 
Management Command (DCMC) personnel at contractor 
facilities. 


_ PMs and DCMC Contract Administration Offices shall 


3.3.6.6 Information 
Sharing and DoD 
Oversight 


jointly develop and approve program support plans for all 
ACAT | program contracts to ensure agreement on 
contract oversight needs and perspectives. 


Assignment of PM technical representatives in a 
contractor's facility shall occur only as necessary, shall 
be based on the mutual agreement of the respective PM 
and the Commander, DCMC, and shail be reflected in a 
Memorandum of Agreement that specifies the duties to 
be performed by the technical representative. 


In these cases, technical representatives shall not 
perform contract administration duties as outlined in FAR 
42.302(a) . 


DoD oversight activities (i.e., contract administration 
offices, contracting offices, technical activities, and 
program management offices) shall consider all relevant 
and credible information that might mitigate risks and the 
need for DoD oversight before designing and applying 
direct DoD oversight of contractor operations. 


DoD buying and technical activities shall provide to the 
Commander, DCMC copies of reviews of contractor 
operations and other documents assessing or rating 
contractor performance or operations. 


Extracted Requirements 


No. 


Subject 


463 PM 


464 


463 


463 


467 


468 


PM 


PM 


PM 


PM 


PM 


Task 


use 


plan 


use 


use 


plan 


provide 


Object Modifier Using 
DCMC 


contract oversight ensure agreement. 
with DCMC 


DCMC 


DCMC 


contract oversight to mitigate risks and 
DOD oversight 


contractor reviews to DCMC 





Applicable DoD 5000.2R Statements 


| 3.3.7 The acquisition strategy shall include a programmatic 
| Environmental, environmental, safety, and health (ESH) evaluation. 

| Safety, and Health. 

| Considerations 


The PM shall initiate the ESH evaluation at the earliest 
possible time in support of a program initiation decision 
(usually Milestone |!) and shall maintain an updated 
evaluation throughout the life cycle of the program. 


3.3.8 Source of Support concepts for new and modified systems shall 

Support maximize the use of contractor provided, long-term, total 
life cycle logistics support that combines depot-ievel 
maintenance for non-core-related workload along with 
wholesale and selected retail materiel management 
functions. 


~ 


Eel 


Best value over the life cycle of the weapon system and 

use of existing contractor capabilities, particularly while 
the system is in production, shall be key determinants in 
the overall decision process. 


The PM shall provide for long-term access to data 
required for competitive sourcing of systems support 
throughout its life cycle. : 


3.3.9 Warranties 10USC 2403 mandates the use of warranties in 
weapon system production that apply to essential 
performance requirements as well as design and 
manufacturing, and materials and workmanship. 





Extracted Requirements 


No. 
469 


470 


471. 


472 


473 


474 


475 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


conduct 


conduct 


use 


use 


use 


obtain 


use 


Object 
ESH evaluation 


ESH evaluation 


contractor support 


best value 


existing contractor 
capabilities 


data 


warranties 


Modifier Using 


acquisition 
strategy 


acquisition 
strategy 


for non-core-related 
work 


for. competitive contract 
sourcing of systems 
Support 


IAW 10 USC 2403 contract 
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Applicable DoD 5000.2R Statements | Extracted Requirements 


No. Subject Task Object Modifier Using 

3.3.9 Warranties |The PM shall incorporate warranty requirements into 476 PM use warranties IAW DFARS 246.770 _ contract 
program contracts in accordance with DFARS 246.770 , 

unless a waiver is approved consistent with DFARS 

246.770-8 . 
3.4 Test and Test and evaluation programs shall be structured to 477 PM coordinate modeling, 
Evaluation integrate all developmental test and evaluation (DT&E), | simulation and test 

operational test and evaluation (OT&E), live-fire test and activities 

evaluation (LFT&E), and modeling and simulation 

activities conducted by different agencies as an efficient 

continuum. 

All such activities shall be part of a strategy to provide 478 PM plan data collection for risk and risk modeling, 

information regarding risk and risk mitigation, to provide mitigation simulation and 


empirical data to validate models and simulations, to 
permit an assessment of the attainment of technical 
performance specifications and system maturity, and to 
determine whether systems are operationally effective, 
suitable, and survivable for intended use. 


test strategy 


479 PM plan data collection to validate models and modeling, 
simulations simulation and 
test strategy 
480 PM plan data collection assess technical modeling, 
performance simulation and 


test strategy 


481 PM plan data collection assess system modeling, 
maturity simulation and 
test strategy 
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Applicable DoD 5000.2R Statements 


3.4 Test and 
Evaluation 


All such activities shall be part of a strategy to provide 
information regarding risk and risk mitigation, to provide 
empirical data to validate models and simulations, to 
permit an assessment of the attainment of technical 
performance specifications and system maturity, and to 
determine whether systems are operationally effective, 
suitable, and survivable for intended use. 


For ACAT | and |i programs for conventional weapons 
systems designed for use in combat, a beyond low-rate 
initial production decision shall be supported by 
completed independent initial operational test and 
evaluation as required by 10 USC 2399 and by 
completed live fire test and evaluation as required by 10 
USC 2366. , 


Operational test and evaluation does not include an 
operational assessment based exclusively on computer 
modeling, simulation, or an analysis of system 
requirements, engineering proposals, design 


specification, or any other information contained in program documents (10 USC 2399 ). 


Extracted Requirements 
No. Subject Task 


482 PM 


483 PM 


484 PM 


485 PM 


486 PM 


487 PM 


plan 


plan 


plan 


accomplish 


accomplish 


collect 


Object 
data collection 


data collection 


data collection 


 1OT&E 


LFT&E 


data 


Modifier 


determine operational 
effectiveness 


determine operational 
suitability 


determine operational 
survivability 


prior to a beyond 
low-rate initial 
production decision 


prior to a beyond 
low-rate initial 
production decision 


for OT&E 





Using 
modeling, 
simulation and 
test strategy 


modeling, 
simulation and 
test strategy 


modeling, 
simulation and 
test strategy 


Ovl 


Applicable DoD 5000.2R Statements Extracted Requirements 


3.4.1 Test and 
Evaluation Strategy 


Test and evaluation planning shall begin in Phase 0, 
Concept Exploration. 


Both developmental and operational testers shall be 
involved early to ensure that the test program for the 
most promising alternative can support the acquisition 
strategy and to ensure the harmonization of objectives, 
thresholds, and measures of effectiveness (MOEs) in 
the ORD and TEMP. 


Test and evaluation planning shall address MOEs and 
measures of performance (MORs) with appropriate 
quantitative criteria, test event or scenario description, 
resource requirements (e.g., special instrumentation, 
test articles, validated threat targets, validated threat 
simulators and validated threat simulations, actual threat 
systems or surrogates, and personnel), and identify test . 
limitations. 


No. 
488 


Subject 
PM 


489 PM 


490 PM 


491 


492 © 


493 


494 


495 


PM 


PM 


PM 


PM 


Task 
plan 


involve 


address 


address 


address 


address 


address 


address 


Object Modifier 
T&E 


testers 


test MOEs 


test MOPs 


test quantitative 
criteria 


test events 


test scenario 
descriptions 


test resource 
requirements 


Using 


test planning 


test planning 


test planning 


test planning 


test planning 


test planning 


[vl 


Applicable DoD 5000.2R Statements 


3.4.1 Test and 
Evaluation Strategy 


Test and evaluation planning shall address MOEs and 
measures of performance (MOPs) with appropriate 
quantitative criteria, test event or scenario description, 


_ resource requirements (e.g., special instrumentation, 


test articles, validated threat targets, validated threat 
simulators and validated threat simulations, actual threat 
systems or surrogates, and personne!), and identify test 
limitations. 


Test planning, at a minimum, shall address ail system 
components (hardware, software and human 
interfaces) that are critical to the achievement and 
demonstration of contract technical performance 
specifications and operational effectiveness and 
suitability requirements from the ORD. 


Quantitative criteria shall be phased so as to provide 
substantive evidence for analysis of hardware, 

software and system maturity and readiness to proceed 
through the acquisition process. 


Extracted Requirements 
Subject Task 


No. 
496 


497 


498 


499 


500 


501 


502 


503 


PM 


PM 


PM 
PM 
PM 


PM 


PM 


PM 


address 


address 


address 


address 


address 


establish 


establish 


establish 


Object 
test limitations 


all system 
components 


hardware 
software 
human interfaces 


quantitative test 
criteria 


quantitative test 
criteria 


quantitative test 
criteria 


Modifier 


for analysis of 
hardware 


for analysis of 
software 


for analysis of system 
maturity 


Using 
test planning 


test planning 


test planning 
test planning 
test planning 


test planning 


test planning 


test planning 
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Applicable DoD 5000.2R Statements 


3.4.1 Test and Linkage shall exist among the various MOEs and MOPs 

Evaluation Strategy used in the analysis of alternatives or ORD, and test and 
evaluation; in particular, the MOEs, MOPs, and criteria in 
the ORD, the analysis of alternatives, the TEMP and the 
APB shall be consistent. + 


Test and evaluation planning must provide for completion 
of Initial Operational Test and Evaluation (IOT&E) and 
Live Fire Test and Evaluation (LFT&E), as required, 
before entering full-rate production. 


Extracted Requirements 


No. 
504 


505 


506 


507 


508 


509 


510 


511. 


Subject Task 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


link 


link 


link 


link 


link 


link 


plan 


plan 


Object 
MOEs 


MOPs 

ORD criteria 
analysis of 
alternative criteria 
TEMP criteria 


APB criteria 


lIOT&E 


LFT&E 


Modifier 


with other program 
criteria 


with other program 
criteria 


with other program 
criteria 


with other program 
criteria 


with other program 
criteria 


with other program 
criteria 


complete 


complete 


Using 

test planning 
test Pee 
test planning 
test planning 
test planning 
test planning 


test planning 


test planning 
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Applicable DoD 5000.2R Statements 


No. 
3.4.1 Test and Test planning for these items (commercial and 512 
Evaluation Strategy non-developmental items) shall include consideration of 
operational testing and LFT&E needed to assure 
effective performance in the intended operational 
environment. 


913 


However, the test program shall be tailored to recognize 514 
commercial testing and experience. 


515 
Testing shall be planned and conducted to take full 516 
advantage of existing investment in DoD ranges, 
facilities, and other resources, wherever practical, 
unless otherwise justified in the TEMP. 
517 
518 


Early testing of prototypes in Phase |, Program Definition 519 
and Risk Reduction, and early operational assessments 
shall be emphasized to assist in identifying risks. 


Subject Task 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


consider 


consider 


analyze 


tailor 


consider 


consider 


consider 


identify 


Extracted Requirements 


Object 
LFT&E 


lIOT&E 


commercial items 
testing 


existing DOD 
ranges 


existing DOD 
facilities 


other existing DOD 
resources 


risk 





Modifier 
for commercial items 


for NDI 


for commercial testing 
and experience 


for commercial testing 
and experience 


Using 
test planning 


test planning 


test planning 
test planning 


test planning 


test planning: 
test planning 


EUT&E 


vrt 


Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
3.4.1 Test and Modeling and simulation shall be an integral part of test 520 PM use modeling and test planning 
Evaluation Strategy and evaluation planning. simulation 
A final independent phase of operational test and 521 PM conduct OT&E prior to a beyond 
evaluation shall be required for beyond low-rate initial low-rate initial 


production (LRIP) decisions. production decision 


3.4.2 Identify potential operational and technological 522 PM measure system DT&E 
Developmental Test capabilities and limitations of the alternative concepts performance 
and Evaluation and design options being pursued capability 
Support the identification of cost-performance trade-offs 523 PM measure alternative system DT&E 
by providing analyses of the capabilities and limitations performance 
of alternatives r . capability 
Support the identification and description of design 522 PM measure system DT&E 
technical risks performance 
' capability 
Assess progress toward meeting Critical Operational 522 PM measure system DT&E 
Issues, mitigation of acquisition technical risk, performance 
achievement of manufacturing process requirements capability 


and system maturity 


Assess validity of assumptions and conclusions from 522 PM measure system ; DT&E 
the analysis of alternatives performance | 

capability 
Provide data and analysis in support of the decision to 522 PM measure system DT&E 
certify the system ready for operational test and performance 


evaluation capability 





crl 


Applicable DoD 5000.2R Statements 


3.4.2 in the case of automated information systems, support 
Developmental Test an information systems security certification prior to 
and Evaluation processing classified or sensitive data and ensure a 


standards conformance certification. 


3.4.3 Certification The developing agency shall prepare a DT&E Report, 

of Readiness for and formally certify that the system is ready for the next 

Operational Test . dedicated phase of operational test and evaluation to be 

and Evaluation conducted by the DoD Component operational test 
activity. 


The developing agency shail establish maturity criteria 
and performance exit criteria necessary for certification 
for operational test. 


In support of this, risk management measures and 
indicators, with associated thresholds, which address 
performance and technical adequacy of both hardware 
and software shali be defined and used on each 
program. 


A mission impact analysis of criteria and thresholds that 
have not been met shall be completed prior to 
certification for operational tests. 


3.4.4 Modeling and PMs shall integrate the use of modeling and simulation 

Simulation within program planning activities, plan for life cycle 
application, support, and reuse models and simulations, 
and integrate modeling and simulation across the 
functional disciplines. 


Extracted Requirements 


No. Subject Task Object 

522 PM measure system 
performance 
capability 

529 PM certify system 
performance 
capability 

530 -PM establish criteria 

531 PM establish hardware criteria 

532 PM establish software criteria 

533 PM analyze impact on mission 

534 PM use modeling and 
simulation 





Modifier Using 
DT&E 


prior to operational DT&E Report 
test 


for entrance into 
operational test 


for entrance into 
operational test 


for entrance into 
operational test 


of system operational 
test criteria not 
achieved 
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; Applicable DoD 5000.2R Statements 


3.4.4 Modeling and 
Simulation 


3.4.5 Operational 
Test and Evaluation 


PMs shall integrate the use of modeling and simulation 
within program planning activities, plan for life cycle 
application, support, and reuse models and simulations, 
and integrate modeling and simulation across the 
functional disciplines. 


Operational test and evaluation (OT&E) programs shall 
be structured to determine the operational effectiveness 
and suitability of a system under realistic conditions 
(e.g., combat) and to determine if the minimum 
acceptable operational performance requirements as 
specified in the ORD have been satisfied. 


Extracted Requirements 


No. 
535 


936 


537 


538 


539 


540 


541 


Subject 
PM 


PM . 


PM 


PM 


PM 


PM 


PM 


Task 


plan 


plan 


plan 


integrate 


structure 


structure 


structure 


Object 


modeling and 
simulation 


modeling and 
simulation 


modeling and 
simulation 


modeling and 
simulation 


OT&E 


OT&E . 


OT&E 


Modifier 


for life cycle 
application 


for life cycle support 


for reuse 


across functional 
disciplines 


to determine 
operational 
effectiveness under 
realistic conditions 


to determine 
operational suitability 
under realistic 
conditions 


to determine if 
operational 
performance in ORD 
have been satisfied 


Using 








Applicable DoD 5000.2R Statements 


3.4.5 Operational Threat or threat representative forces, targets, and 
Fest and Evaluation threat countermeasures, validated in coordination with 
DIA, shall be used. 


4 


Typical users shall operate and maintain the system or 
item under conditions simulating combat stress and 
peacetime conditions. 


Lvl 


The independent operational test activities shall use 
production or production representative articles for the 
dedicated phase of OT&E that supports the full-rate 
production decision, or for ACAT IA or other acquisition 
programs, the deployment decision. ; 


The use of modeling and simulation shall be considered 
during test planning. . 


Extracted Requirements 


No. 


Subject 


542 PM 


543: 


544 


545 


546 


547 


548 


549 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


use 


use 


use 


use 


use 


uss 


use 


consider 


Object 


threat or threat 
representative 
forces 


threat or threat 
representative 
targets 


threat 
countermeasures 


typical users 


typical users 


typical users 


production 
representative 
articles 


modeling and 
simulation 


Modifier 
in OT&E 


in OT&E 


in OT&E coordinated 
with DIA 


to operate OT&E 
system 


to operate OT&E 
system under 
stressful conditions 


to operate OT&E 
system under 
peacetime conditions 


for OT&E 


during OT&E planning 


Using 


3Vl 


Applicable DoD 5000.2R Statements 


3.4.5 Operational 
Test and Evaluation 


as a condition for proceeding beyond LRIP, initial 
operational test and evaluation shall not comprise an 
operational assessment based exclusively on computer 
modeling; simulation; or, an analysis of system 


requirements, engineering proposals, design 


specifications, or any other information contained in 
program documents (10 USC 2399 }. _ 


The extent of modeling and simulation usage in 
conjunction with operational and test evaluation shall be 
explained in the Test and Evaluation Master Plan (see 
3.4.11). 


All hardware and software alterations that materially 
change system performance (operational effectiveness 


and suitability) shall be adequately tested and evaluated. 


This includes system upgrades as well as changes . 
made to correct deficiencies identified during test and 
evaluation. 


- Conduct an OT&E before full-rate production to evaluate 


operational effectiveness and suitability as required by 
10 USC 2399 for ACAT | and II programs. 


Operational Test Agencies shall participate early in 
program development to provide operational insights to 
the program office and to acquisition decisionmakers. 


Operational testing and evaluation shall be structured to 
take maximum advantage of training and exercise 
activities to increase the realism and scope of 
operational testing and to reduce testing costs. 


Extracted Requirements 


No. 


Subject 


550 PM 


991 


552 


553 


554 


555 


PM 


PM 


PM 


PM 


PM 


Task 
evaluate 


document 


test 


conduct 


involve 


use 


Object 


system 
performance 
capability 


modeling and 
simulation 


all hardware and 
software 


OT&E 


testers 


training and 
exercise activities 


Modifier 


as opposed to 
documented plans 


after modification 


prior to full-rate 
production 


during OT&E planning 


Using 
test and 
evaluation 


TEMP 
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Applicable DoD 5000.2R Statements 


3.4.6 Operational The DOT&E shall approve, in writing, the adequacy of 

Test and Evaluation the OT&E plans (including project funding) for all ACAT | 

Plans and ACAT IAM programs and other designated programs 
prior to the initiation of operational testing. 


Plans for all operational assessments of programs on 
DOT&E's oversight list being conducted to support 
acquisition decisions such as LRIP or release of funds 
for long lead shall be approved by DOT&E prior to their 
execution. 


DoD Components shall brief the DOT&E on the concepts 
for the test and evaluation or assessment 120 days prior 
to commencement and submit the test plan to the 
DOT&E 60 days prior to commencement. 


~ 


These test plans shall include test objectives, measures 
of effectiveness, planned operational scenarios, threat 
simulation, resources, test limitations, and methods of 
data gathering, reduction, and analysis. 


Extracted Requirements 


No. 
556 


557 


558 


559 


560 


561 


562 


563 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
obtain 


obtain 


brief 


notify 


pian 


plan 


_ plan 


plan 


Object 


DOT&E approval 


DOT&E approval 


DOT&E 


DOT&E 


test objectives 


MOE's 


* 


operational 
scenarios 


threat simulation 


Modifier Using 
for OT&E plans 


for operational 
assessments 


120 days prior to 
commencement of 
OT&E 


60 days prior to test plan 
commencement of 
OT&E 


test plan 


test plan 


test plan 


test plan 


OSI 


Applicable DoD 5000.2R Statements | Extracted Requirements 


No. Subject Task Object Modifier Using 
3.4.6 Operational These test plans shall include test objectives, measures 564 PM plan resources test plan 
Test and Evaluation of effectiveness, planned operational scenarios, threat 
Plans simulation, resources, test limitations, and methods of 
data gathering, reduction, and analysis. 
565 PM plan test limitations test plan 
566 PM plan methods of data test plan 
gathering 
567 PM plan methods of data test plan 
reduction 
568 PM plan methods of data test plan 
analysis 
The planned test events shall be described in sufficient 569 PM document test plans to allow assessment 
detail to permit an assessment of operational realism. of operational realism 
3.4.7 Use of The use of system contractors in support of the OT&E 570 PM conduct OT&E IAW 10 USC 2399 
system conducted to support a decision to proceed beyond 
Contractors in low-rate initial production is restricted by 10 USC 2399 . 
Support of 
Operational Test 
and Evaluation 
3.4.8 Production Production qualification test and evaluation shall be 571 PM conduct production prior to full-rate 
Qualification Test | completed prior to the full rate production decision. | qualification test production 


and Evaluation 





[ST 


Applicable DoD 5000.2R Statements 


3.4.9. Live Fire 
Test and Evaluation 


Live Fire Test and Evaluation (LFT&E), as that term is 
defined in 10 USC 2366 must be conducted ona 
covered system, major munition program, missile 
program, or product improvement to a covered system, 
major munition program, or missile program before it can 
proceed beyond low-rate initial production. 


Survivability testing shall begin at the component, 
subsystem, and subassembly level, culminating with 
tests of the complete covered system or program, or 
covered product improvement, configured for combat. 


Waivers and the use of alternative survivability and 
lethality testing shall be addressed in the TEMP for the 
covered system, program, or covered product 
improvement program. CAE certifications and reports 
required under 10 USC 2366(c) shall be submitted to 
Congress through the DOT&E and the USD(A&T). 


Waivers and the use of alternative survivability and 
lethality testing shall be addressed in the TEMP for the 
covered system, program, or covered product 
improvement program. 





Extracted Requirements 
Subject Task 


No. 
572 


573 


574 


575 


576 


577 


578 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


conduct 


conduct 


conduct 
conduct 


plan 


plan 


plan 


Object . Modifier Using 
LFT&E prior to full-rate 
production 


survivability testing of components 


survivability testing of subsystems 
survivability testing of subassemplies 


waivers TEMP 


alternative TEMP 
survivability testing 


alternative lethality TEMP 
testing 


CST 


Applicable DoD 5000.2R Statements 


3.4.9. Live Fire 
Test and Evaluation 


3.4.11 Test and 
Evaluation Master 
Plan 


No. 


CAE certifications and reports required under 10 USC 579 
2366(c) shall be submitted to Congress through the 
DOT&E and the USD(A&T), 


580 


The Test and Evaluation Master Plan (TEMP) shall focus 581 
on the overall structure, major elements, and objectives 

of the test and evaluation program that is consistent with 

the acquisition strategy. 


582 


583 


be prepared for all ACAT | and ACAT IA programs and 584 
other acquisition programs designated for DOT&E or 

Office of the Secretary of Defense test and evaluation 
oversight (10 USC 2399 ) 


be approved by the DOT&E and the DTSE&E for all ACAT 585 
| and ACAT IAM programs and other designated 
programs 


provide a road map for integrated simulation, test, and 586 
evaluation plans, schedules, and resource requirements 
necessary to accomplish the test and evaluation 

program. 


Subject Task 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


prepare 


submit 


plan 


plan 


plan 


plan 


obtain 


integrate 


Extracted Requirements 


Object 
reports 


reports 


overall test 
structure 


major test elements 


objectives of test 
and eval 


test and evaluation 


approval 


simulation, T&E, 
schedules, and 
resource 
requirements 


Modifier Using 
IAW 10 USC 2366© 


to congress through 
DOT&E 


TEMP 


TEMP 


TEMP 


TEMP 


TEMP 


TEMP 





eCl 








Applicable DoD 5000.2R Statements 


3.5 Life Cycle 
Resource 
Estimates 


3.5.1 Life Cycle 
Cost Estimates 


For all ACAT | and !A programs,.a life cycle cost 
estimate shall be prepared by the program office in 
support of program initiation (usually Milestone |) and all 
subsequent milestone reviews. 


For ACAT | programs, a manpower estimate shall be 
prepared by the Component's manpower authority in 
support of Milestone Il and Milestone III. 


For ACAT | programs, the MDA may not approve entry 
into engineering and manufacturing development or 
production and deployment unless an independent 


. estimate of the full life cycle cost of the program and a 
_ manpower estimate for the program have been 


completed and considered by the MDA (10 USC 2434 ). 


Explicitly based on the program objectives, operational 
requirements, contract specifications for the system, 
and, for ACAT | programs, a program DoD work 
breakdown structure (WBS) or, for ACAT IA programs, 
a life cycle cost and benefit element structure agreed 
upon by the IPT 


Comprehensive in character, identifying all elements of 
cost that would be entailed by a decision to proceed 
with development, production, and operation of the 
system regardless of funding’source or management 








Extracted Requirements 


No. 


587 PM 


588 


589 


590 


591 


592 


PM 


PM 


PM 


PM 


PM 


Subject Task 


prepare 


prepare 


obtain 


obtain 


prepare 


prepare 


Object Modifier Using 


life cycle cost 
estimate 


manpower 


independent 
life cycle cost 


independent 
manpower 
estimates 


WBS 


life cycle cost that is comprehensive 
estimate 


VSI 


Applicable DoD 5000.2R Statements 


3.5.1 Life Cycle For ACAT | programs, consistent with the cost estimates 

Cost Estimates used in the analysis of alternatives, the manpower 
estimates behind the operation and support costs shall 
be consistent with the manpower estimate 


Neither optimistic nor pessimistic, but based on a careful 
assessment of risks and reflecting a realistic appraisal 
of the level of cost most likely to be realized. 


Cost Analysis . For ACAT | programs, the DoD Component sponsoring 

Requirements the acquisition program shall establish, as a basis for the 

Description (CARD) lifé cycle cost estimates, a description of the salient 
features of the acquisition program and of the system 
itself. 


(CARD), shall be given to the teams preparing the 
program office life cycle estimate, component cost 
analysis, and independent life cycle cost estimate 180 
days in advance of a planned Overarching Integrated 
Product Team (OIPT) or Component review, unless 
another due date is agreed to by the OIPT. 


The CARD shall be flexible, tailored, and make reference 
to information available in other documents available to 
the cost estimators. 


For joint programs, the CARD shall include the common 
program as agreed to by all participating DoD 


Components as well as ail unique program requirements - 


of the participating DoD Components. 


Extracted Requirements 


No. 


Subject 


593 PM 


594 


995 


596 


597 


598 


596, 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
coordinate 


prepare 


prepare 


establish 


provide 


provide 


establish 


Object 


cost estimates with 


manpower 


estimates 


life cycle cost 
estimate 


life cycle cost 
estimate 


a description of the 
system 


a description of the 
system 


system information 


a description of the 
system 


Modifier Using 


based on a careful 
assessment of risks 


reflecting a realistic 
appraisal of cost 


CARD 


to team preparing life CARD 
cycle cost estimates 
180 days prior to OIPT 


that is tailored and CARD 
refers to other 
documents 


CARD 


SSI 


Applicable DoD 5000.2R Statements 


For ACAT IA programs, the PM shall prepare the CARD 
in coordination with the appropriate IPT members. 


Cost Analysis 
Requirements 
Description (CARD) 


Address whether the program is affordable from a 
military end strength and civilian work year perspective 


3.5.2 Manpower 
Estimates shall: 


Clearly state the risks associated with achieving 
manpower numbers reported in the estimate 


_ Consider the program objectives, but shall base the 
estimate on a careful assessment of the risks anda 
realistic appraisal of the level of improvements most 
likely to be realized. 


The manpower estimate shall report the total number of © 


personnel needed to operate, maintain, support, and 
provide training for the program upon full operational 
deployment. 


Extracted Requirements 
Subject Task 


No. 
600 


601 


602 


603 


604 


605 


606 


607 


PM 


PM | 


PM 


PM 


PM 


PM 


PM 


PM 


establish 


assess 


assess 


assess 


_ determine 


determine 


determine 


determine 


Object 


a description of the 


system 


program 
affordability 


manpower 
estimate risks 


risks 


tota! personnel 


total personnel 


total personnel 


total personnel 





Modifier 
using PTs 


from a military end 
strength and civilian 
work year perspective 


from a military end 
strength and civilian 
work year perspective 


using a realistic 
appraisal 


to operate system 


to maintain system 
to support system 


to provide training for 
the system 


Using 
CARD 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 
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Applicable DoD 5000.2R Statements 


3.5.2 Manpower 
Estimates shall: 


It shall report the number of military (officer, warrant 
officer, and enlisted), DoD civilian, and contract 
manpower requirements for each fiscal year of the 
program beginning with initial fielding and ending with full 
operational deployment. 


A separate estimate shall be provided for each 
Component (for joint programs) and separately for the 
Active, Reserve, and National Guard forces. 


Extracted Requirements 


No. 
608 


609 


610 


611 


612 


613 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


Task 
determine 


determine 


determine 


determine 


determine 


determine 


Object 
total personnel 


total personnel 


total personnel 


total personnel! 


total personnel 


total personnel 


Modifier 


that are officer per 
fiscal year from initial 
fielding to full 
operational 
deployment 


that are warrant 
officer per fiscal year 
from initial fielding to 
full operational 
deployment 


that are enlisted per 
fiscal year from initial 
fielding to full 
operational 
deployment 


that are DoD civilian 
per fiscal year from 
initial fielding to full 
operational 
deployment 


that are contractor per 
fiscal year from initial 
fielding to full 
operational 
deployment 


for each component 


Using 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 
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Applicable DoD 5000.2R Statements 


3.5.2 Manpower 
Estimates shall: 


A separate estimate shall be provided for each 
Component (for joint programs) and separately for the 
Active, Reserve, and National Guard forces. 


The estimate shall report manpower requirements and 
authorizations (as military end-strengths and civilian 
work years) for each fiscal year, and shail indicate if 
there are any resource shortfalls for any fiscal year | 
covered in the report. 


The report shall state whether any increase in military 
end strengths or civilian work years (beyond what is 
included in the Future Years Defense Program) or 
whether waivers to existing manpower constraints will 
be required to support full operational deployment of the 
system. 


Extracted Requirements 
Subject Task 


No. 
614 


615 


616 


617 


618 


619 


620 


PM 


PM 


PM 


-PM 


PM 


PM 


PM 


determine 


determine 


determine 


determine 


determine 


determine 


evaluate 


Object 
total personnel 


total personnel 


total personnel 


total personne} 


total personnel 


resource shortfalls 


manpower 





Modifier 
for active forces 


for reserve forces 
for National Guard 


forces 


as military 
end-strengths 


as civilian work years 


against FYDP 


Using 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


manpower 
estimate 


8ST 


_ Applicable DoD 5000.2R Statements 


3.5.2 Manpower 
Estimates shall: 


4.2 integrated 
Product and 
Process 
Development 


4.3 Systems 
Engineering 


No. 
The report shall also address whether the manpower 621 
requirements represent an increase over what was 
required for the predecessor (replaced) system(s), as 
appropriate, and whether the manpower objectives and 
thresholds in the ORD, if established, were met or 
exceeded. 

622 


The PM shall employ the concept of Integrated Product 623 
and Process Development (IPPD) throughout the program 
design process to the maximum extent practicable. 


The IPPD management process shall integrate all 624 
activities from product concept through production and 

field support, using multidisciplinary teams to 

simultaneously optimize the product and its 

manufacturing and supportability to meet cost and 
performance objectives. 


625 


626 


The Program Manager shall ensure that a systems 627 
engineering process is used to translate operational 

needs and/or requirements into a system solution that 
includes the design, manufacturing, test and evaluation, 


_ and support processes and products. 


Subject Task 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


evaluate 


evaluate 


use 


integrate 


USE 


use 


use 


Extracted Requirements 


Object Modifier 

manpower against predecessor 
system 

manpower against ORD values 

IPPD 


system functions from product concept 


through field support 
multidisciplinary 
teams 
concurrent of manufacturing and 
optimization supportability against 
cost and performance 
process 


Using 
manpower 
estimate 


manpower 
estimate 


IPPD 


IPPD 


IPPD 


IPPD 


systems 
engineering 
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Applicable DoD 5000.2R Statements 


4.3 Systems 


Engineering 


The systems engineering process shall establish a 
proper balance between performance, risk, cost, and 
schedule, employing a top-down iterative process of 
requirements analysis, functional analysis and allocation, 
- design synthesis and verification, and system analysis 


and control. 


Extracted Requirements 


No. 
628 
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631 
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633 


634 


635 


636 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Subject Task 
balance 


use 


use 


use 


use 


use 


use 


use 


use 


Object 


cost, schedule, 
performance and 
risk 


top down design 


process 


iterative design 
process 


requirements 
analysis 


functional analysis 
and allocation 
design synthesis 
design verification 


system analysis 


control 


Modifier 


Using 
systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 
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Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
4.3 Systems Transform operational needs and requirements 637 PM use concurrent systems 
Engineering (reference Appendix II) into an integrated system design optimization engineering 
solution through concurrent consideration of all life cycle 
needs (i.e., development, manufacturing, test and 
evaluation, verification, deployment, operations, support, 
training and disposal). 
Ensure the compatibility, interoperability and integration 638 PM ensure compatibility of all functional and systems — 
of all functional and physical interfaces and ensure that physical interfaces engineering 
system definition and design reflect the requirements for 
all system elements: hardware, software, facilities, 
people, and data 
639 PM ensure interoperability of all functional and systems 
physical interfaces engineering 
640 PM ensure integration of all functional and systems 
physical interfaces engineering 
641 PM define system for all system systems 


elements (hardware, engineering 
software, facilities, 
people, and data) 


Characterize and manage technical risks. ° 642 PM characterize risks systems 
engineering 
643 PM manage risks. systems 





engineering 


Applicable DoD 5000.2R Statements 


Requirements 
Analysis. 


TOT 


Functional 
Analysis/Allocation 


Throughout the acquisition process the program office 
shall work with the user to establish and refine 
operational and design requirements that result in the 
proper balance between performance and cost within 
affordability constraints. 


Requirements analysis shall be conducted iteratively 
with functional analysis/allocation to develop and refine 
system level functional and performance requirements, 
external interfaces and provide traceability among user 
requirements and design requirements. 


Functional analysis/allocation shall be performed 
iteratively to define successively lower level functional 
and performance requirements, including functional 
interfaces and architecture. 


Extracted Requirements 


No. 
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PM 
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Task 
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use 
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develop 


provide 


use 


use 


Object 
user 


iterative design 
process 


system level 
functional and 
performance 
requirements 


external interfaces 


traceability 


top down design 
process 


iterative design 
process 


Modifier 


between user 
requirements and 
design requirements 


Using 
systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


col 


Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
Functional Functional analysis/allocation shall be performed 651 PM define functional systems 
Analysis/Allocation iteratively to define successively lower level functional interfaces engineering 
and performance requirements, including functional 
_ interfaces and architecture. 
652 PM define functional | systems 
architecture engineering 
Functional and performance requirements shall be 653 PM provide traceability from functional and systems _ 
traceable to higher level requirements. performance engineering 


requirements to higher 
level requirements 


System requirements shall be allocated and defined in 654 PM allocate requirements to functions systems 
sufficient detail to provide design and verification criteria engineering 
to support the integrated system design. 





655 PM define requirements in sufficient detail for systems 
design and verification engineering 
criteria 
Design Synthesis Design synthesis and verification activities shall 633 PM use design synthesis systems 
and Verification. translate functional and performance requirements into engineering 
design solutions to include: alternative people, product 
and process concepts and solutions, and internal and 
external interfaces. 
657 PM translate requirements into alternative people systems 


concepts and engineering 


col 


Applicable DoD 5000.2R Statements 


Design Synthesis 
and Verification. 


Design synthesis and verification activities shall 
translate functional and performance requirements into 
design solutions to include: alternative people, product 
and process concepts and solutions, and internal and 
external interfaces. 


These design solutions shail be in sufficient detail to - 
verify requirements have been met. 


The verification of the design shall include a 
cost-effective combination of design analysis, design 
modeling and simulation, and demonstration and testing. 


Extracted Requirements 


No. 
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660 
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662 


663 


664 


665 
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PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
translate 


translate 


translate 


define 


verify 


verify 


verify 


verify 


Object 
requirements 


requirements 


requirements 


design solutions 


design 


design 


design 


design 





Modifier 


Using 


into alternative product systems 


concepts and 
solutions 


into alternative 


process concepts and 


solutions 


into internal and | 
external interfaces 


in sufficient detail for 
verification 


design analysis 


design modeling and 
simulation 


design demonstration 


design testing 


engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


Applicable DoD 5000.2R Statements Extracted Requirements 


p9T 


No. Subject Task Object Modifier Using 
Design Synthesis The verification process shall address the design tools, 666 PM verify design tools systems 
and Verification. products, and processes, engineering 
667 PM verify products systems 
engineering 
668 PM verify processes systems 
engineering 
System Analysis |§ System analysis and control activities shall be 635 .PM use system analysis systems 
and Control — established to serve as a basis for evaluating and engineering 
selecting alternatives, measuring progress, and 
documenting design decisions. This shall include: 
636 PM use control systems 
engineering 
The conduct of trade-off studies among requirements 671 PM conduct trade-off analyses systems 
(operational, functional and performance), design engineering 
alternatives and their related manufacturing, testing and 
support processes, program schedule and life cycle 
cost at the appropriate level of detail to support 
decision-making and lead to a proper balance between 
performance and cost. 
The establishment of a risk management process tobe 672 PM establish risk management systems 


applied throughout the design process. ; 


process 


engineering 





col 


Applicable DoD 5000.2R Statements 


System Analysis 


and Control 


The risk management effort shall address the 
identification and evaluation of potential sources of 
technical risks based on the technology being used and 
its related design, manufacturing capabilities, potential 
industry sources, test and support processes, risk 
mitigation efforts, and risk assessment and analysis. 


Extracted Requirements 


No. 
673 
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678 
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identify 
identify 


identify 
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risk 


risk 


risk 


risk 


risk 


risk 


risk 


risk 


risk 








Modifier 
based on technology 


design 
manufacturing 


capabilities 
potential industry 
sources 

test processes 
support processes 
rist mitigation efforts 


risk assessment 


risk analysis 


Using 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


991 


Applicable DoD 5000.2R Statements 


System Analysis 


and Control 


The risk management effort shall address the 
identification and evaluation of potential sources of 
technical risks based on the technology being used and 
its related design, manufacturing capabilities, potential 
industry sources, test and support processes, risk 
mitigation efforts, and risk assessment and analysis. 


Extracted Requirements 


No. 
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688 


689 


690 
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PM 


PM 
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PM 


PM 


PM 
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evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


Object 
risk 


risk 


risk 


risk 


risk 


risk 


risk 


risk 


risk 


Modifier 
based on technology 


design 


manufacturing 


capabilities 


potential industry 


sources 


test processes 


support processes 


rist mitigation efforts 


risk assessment 


risk analysis 


Using 
systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 
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Applicable DoD 5000.2R Statements 


System Analysis 
and Control 


Technology transition planning and criteria shall be 
established as part of the overall risk management 


A configuration management process to control the 


system products, processes and related documentation. 


It shall provide a complete audit trail of decisions and 
design modifications. 


An integrated data management system to capture and 
control the technical baseline (configuration 
documentation, technical data, and technical manuals); 
provide data correlation and traceability among 
requirements, designs, decisions, rationale, and other 
related program planning, and reporting, support 
configuration procedures, and serve as a ready 
reference for the systems engineering effort. 


Extracted Requirements 


No. 
691 


692 


693 


694 


695 


696 


697 


698 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


establish 


plan 


use 


use 


use 


use 


use 


establish 


Object 


technology 
transition 


technology 
transition 


configuration 
management 


configuration 
management 


configuration 
management 


configuration 
management 


configuration 
management 


integrated data 
management 
system 


Modifier 
criteria 


for system products 


for system processes 


for related 


documentation 


for complete audit trail 


of decisions 


for complete audit trail 


of design 


to capture the 
technical baseline 





Using 
systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 





891 


Applicable DoD 5000.2R Statements 


System Analysis 


and Control 


An integrated data management system to capture and 
control the technical baseline (configuration 
documentation, technical data, and technical manuals); 
provide data correlation and traceability among 
requirements, designs, decisions, rationale, and other 
related program planning, and reporting, support 
configuration procedures, and serve as a ready 


reference for the systems engineering effort. 


Extracted Requirements 


No. 
699 


700 


701 


702 


703 


704 


705 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


establish 


establish 


establish 


establish 


establish 


establish 


establish 


Object 


integrated data 
management 
system 


integrated data 
management 
system 


integrated data 
management 
system 


integrated data 
management 
system 


integrated data 
management 
system 


integrated data 
management 
system 


integrated data 
management 
system 


Modifier 


to control the technical 
baseline 


to provide data 
correlation 


for traceability among 
requirements 


for traceability among 
designs 


for traceability among 
decisions 


for traceability among 
rationale 


for other related 
program planning 


Using 
systems 
engineering 


systems 
engineering 


systems 
engineering 


systems 
engineering 


systems - 
engineering 


systems 
engineering 


systems 
engineering 





System Analysis 
and Control 


691 


1.4.3 Phase |: 
Program Definition 
and Risk Reduction 


Applicable DoD 5000.2R Statements 


No. 


An integrated data management system to capture and 706 
control the technical baseline (configuration 

documentation, technical data, and technical manuals); 
provide data correlation and traceability among 

requirements, designs, decisions, rationale, and other 

related program planning, and reporting, support 
configuration procedures, and serve as a ready 

reference for the systems engineering effort. 


707 

708 
PMs shall use existing information systems and data ‘709 
formats rather than DoD-unique systems and formats 
provided they can readily meet the program’s information 
requirements and do not pose compatibility issues with 
operational DoD information systems and data. 

710 


Assessments of the advantages and disadvantages of 045 
alternative concepts shall be refined. 


PM 


PM 


PM 


PM 


PM 


PM 


establish 


establish 


establish 


use 


use 


assess 


Extracted Requirements 
Subject Task 


Object 


integrated data 
management 
system 


integrated data 
management 
system 


integrated data 
management 
system 


existing information 
systems 


existing data 
formats 


concept(s) 
advantages / 
disadvantages 


Modifier Using 

for reporting systems 
engineering 

to support systems 

configuration engineering 

management 

serve as ready , systems — 


reference for systems engineering 
engineering 





OLI 


Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
1.4.3 Phase |: Prototyping, demonstrations, and early operational 046 PM perform prototyping as necessary 
Program Definition assessments shall be considered and included as 
and Risk Reduction necessary to reduce risk so that technology, 
manufacturing, and support risks are well in hand before 
the next decision point. 
047 PM perform demonstrations as necessary 
048 PM perform early operational as necessary 
assessments 
Cost drivers, life cycle cost estimates, 049 PM consider cost-drivers 
cost-performance trades, interoperability, and 
acquisition strategy alternatives shall be considered to 
include evolutionary and incremental! software 
050 PM consider life cycle cost 
estimates 
; 051 PM consider cost-performance 
trades 
052 PM consider interoperability 
053 PM consider acquisition strategy 


alternatives 








IL] 


Applicable DoD 5000.2R Statements 


1.4.3 Phase |: Cost drivers, life cycle cost estimates, 

Program Definition cost-performance trades, interoperability, and 

and Risk Reduction acquisition strategy alternatives shall be considered to 
include evolutionary and incremental software 


System Analysis The establishment of performance metrics to provide 

and Control measures of how well the technical development and 
design are evolving relative to what was planned and 
relative to meeting system requirements in terms of 
performance, risk mitigation, producibility, cost and 
schedule. 


Performance metrics must be traceable to performance 
parameters identified by the operational user. 


Extracted Requirements 
Subject Task 


No. 
054 


055 


711 


712 


713 


714 


715 


716 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


consider 


consider 


establish 


establish 


establish 


establish 


establish 


establish 


Object 


evolutionary 
software 
development 


incremental 
software 
development 


performance 
metrics © 


performance 
metrics 


performance 
metrics 


performance 
metrics 


performance 
metrics 


performance 
metrics 


Modifier 


performance 


risk mitigation 


producibility 


cost 


schedule 


based on parameters 
identified by user 


Using 


CLI 


Applicable DoD 5000.2R Statements 


System Analysis 
and Control 


4.3.1 
Manufacturing and 
Production 


The establishment of interface controls to ensure all 
internal and external interface requirement changes are 
properly recorded and communicated to all affected 
configuration items. 


A structured review process to demonstrate and 
confirm completion of required accomplishments and 
their exit criteria as defined in program planning. 


- Reviews necessary to demonstrate, confirm, and 
~ coordinate progress shall be incorporated into overall 


program planning. 


The producibility of the systern design shall be a priority 
of the development effort. 


Design engineering efforts shall focus on concurrent 
development of producible designs, capable 
manufacturing processes, and process controls to 
ensure requirements satisfaction and minimize 
manufacturing costs. ; 


Extracted Requirements 
Subject Task 


No. 
717 


718 


719 


720 


721 


722 


123 


724 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


establish 


establish 


establish 


establish 


establish 


establish 


consider 


use 


Object 
interface controls 


review process 


review exit criteria 


review process 


review process 
review process 


producibility of the 
design 


concurrent design 
process 


Modifier Using 


for internal and 
external interfaces 
requirement changes 


to demonstrate 
progress 


to confirm progress 


to coordinate progress 


for designs 








eLi 


Applicable DoD 5000.2R Statements 


4.3.1 
Manufacturing and 
Production 


Design engineering efforts shall focus on concurrent 
development of producible designs, capable 
manufacturing processes, and process controls to 
ensure requirements satisfaction and minimize 
manufacturing costs. 


-~ 


The use of existing manufacturing processes shall be 
capitalized upon whenever possible. 


When new manufacturing capabilities are required, 
flexibility (i.e., insensitivity to rate and product 
configuration) shall be considered. 


Full rate production of a system shall not be approved 
until the system’s design has been stabilized, the 
manufacturing processes have been proven, and the 
production facilities and equipment are in place (or are 
being put in place). 


Extracted Requirements 


No. Subject Task Object 

725 PM use concurrent design 
process 

726 PM use concurrent design 
process 

727 PM use existing 
manufacturing 
processes 

728 PM consider flexible 
manufacturing 
processes 

729 PM stabilize design 

730 PM prove manufacturing 
processes 

731 PM organize production facilities 


and equipment 


Modifier 


for manufacturing 
processes 


Using 


for process controls 


prior to full rate 
production 


prior to full rate 
production 


prior to full rate 
production 


vLt 


Applicable DoD 5000.2R Statements 


4.3.2 Quality 


The PM shall aflow contractors the flexibility to define 
and use their preferred quality management process that 
meets program objectives. 


Third party certification or registration of a supplier's 


quality system shail not be required. 


The quality management process shall include Monitoring 
and control of critical processes and product variation 


The quality management process shall include 
Establishment of mechanisms for feedback of field 
product performance 


The quality management process shall include 
Implementation of an effective root cause analysis and 
corrective action system 


The quality management process shall include 
Continuous process improvement. 


Extracted Requirements 
Subject Task 


No. 
732 


733 


734 


735 


736 


737 


738 


739 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


use 


accept 


establish 


establish 


establish 


establish 


establish 


_ establish 


Object 


contractor's quality 
management 
process 


quality certification 


quality 
management 
process 


quality 
management 
process 


quality feedback 
mechanisms 


quality 
management 
process 


quality 
management 
process 


quality 
management 
process 


Modifier Using 


if meets program 
objectives 


second party 


monitor and control 
critical processes 


monitor and contro! 
product variation 


from field use 


root cause analysis 


corrective action 
system 


continuous process 
improvement 





Applicable DoD 5000.2R Statements 


4.3.3 Acquisition 
Logistics 


4.3.3.1 
Supportability 
Analyses 


SLI 


1.4.4.1 Low Rate 
Initial Production 


4.3.3.1 
Supportability 
Analyses 


No. 


The PM shall conduct acquisition logistics management 740 
activities throughout the system development to ensure 

the design and acquisition of systems that can be 
cost-effectively supported and to ensure that.these 

systems are provided to the user with the necessary 

support infrastructure for achieving the user's 

peacetime and wartime readiness requirements. 


Supportability analyses shall be conducted as an integral 741 
part of the systems engineering process beginning at 
program initiation and continuing throughout program 
development. 


Supportability analyses shall form the basis for related 742 
design requirements included in the system specification 

and for subsequent decisions concerning how to most 
cost-effectively support the system over its entire 

life cycle. 


The LRIP quantity shall not be less than one unit and any 059 
increase shall be approved by the MDA. 


060 


When approved LRIP quantities are expected to be 061 
exceeded because the program has not yet 

demonstrated readiness to proceed to full-rate 

production, the MDA shall assess the cost and benefits 

of a break in production versus annual buys. 


Programs shall allow contractors the maximum flexibility 743 
in proposing the most appropriate supportability 
analyses. 


PM 


PM 


PM 


Both 


MDA 


MDA 


PM 


Task 
conduct 


conduct 


establish 


plan 


approve 


assess 


use 


Extracted Requirements 
Subject 


Object 


acquisition logistics 


management 


supportability 
analysis 


requirements 


LRIP quantities 


LRIP quantities 
increases 





Modifier Using 
systems 
engineering 

based on systems 


supportability analysis engineering 


>= 1 unit 


break in production when LRIP quantities 


contractor's 
supportability 
analysis 


expect to be 


9LT 


Applicable DoD 5000.2R Statements 


4.3.3.2 Support 
Concepts 


4.3.3.3 Support 
Data 


4.3.3.4 Support 
Resources 


Acquisition programs shall establish logistics support 
concepts (e.g., two level, three level) early in the 
program and refine them throughout the development 
process. 


Life cycle costs shall play a key role in the overall 
selection process. 


Support concepts for new and future weapon systems 
shall provide for cost effective total life cycle logistics 
support. 


Data requirements shall be consistent with the planned 
support concept and represent the minimum essential to 


’ effectively support the fielded system. 


Government requirements for contractor developed 
support data shall be coordinated with the data 
requirements of other program functional specialties to 


_ minimize data redundancies and inconsistencies. 


Support resources such as operator and maintenance 
manuals, tools, support equipment, training devices, etc. 
for major weapon system components shall not be 
procured before the weapon system/component 
hardware and software design stabilizes. 


Extracted Requirements 


No. 
744 


745 


746 


747 


748 


749 


750 


751 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
establish 


use 


define 


obtain 


obtain 


coordinate 


procure 


procure 


Object 


logistic support 
concepts 


life cycle costs 


support concepts 


support data 


support data 


support data 


support resources 


operator manuals 


Modifier Using 


to make decisions 


to make total life cycle 
logistics support cost 
effective 


consistent with 
planned support 
concept 


minimum essential to 
support fielded system 


minimum essential for 
all functions 


after system design 
stabilizes 


after system design 
stabilizes 





EL) 


Applicable DoD 5000.2R Statements 


4.3.3.4 Support 
Resources 


Support resources such as operator and maintenance 
manuals, tools, support equipment, training devices, etc. 
for major weapon system components shall not be 
procured before the weapon system/component 
hardware and software design stabilizes. 


The PM shall consider the use of embedded training and 
maintenance techniques to enhance user capability and 
reduce life cycle costs. 


Where they are available, cost-effective, and can readily 
meet the user's requirements, commercial support 
resources shall be used. : 


DoD automatic test system (ATS) families or COTS 
components that meet defined ATS capabilities shall be 
used to meet all acquisition needs for automatic test 
equipment hardware and software. 


Extracted Requirements 


No. 


752 PM 


753 


754 


755 


756 


757 


758 


759° 


PM 


PM. 


PM 


PM 


.PM 


PM 


PM 


Subject Task 


procure 


procure 


procure 


procure 


consider 


use 


use 


use, 


Object Modifier Using 
maintenance after system design 
manuals stabilizes ; 
tools after system design 
stabilizes 


support equipment after system design 


stabilizes 
training devices after system design 
stabilizes 
embedded 
training/maintenanc 
e 


commercial support 
resources 


DOD ATS families for ATE 


COTS components for ATE 


8Li 


Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
4.3.3.4 Support ATS capabilities shall be defined through critical 760 PM define ATS capabilities through critical 
Resources hardware and software elements. hardware and 


software elements 


The introduction of unique types of ATS into the DoD 761 PM analyze automated test cost/benefit 
field, depot, and manufacturing operations shall be equipment analysis 
minimized, and the selection shall be based on a cost requirements 


- and benefit analysis that ensures that the ATS chosen is 
the most beneficial to the DoD over the system life 


4.3.4 Open PMs shall address the use of open standards in the 762 PM assess open standards ail system elements 
Systems Design design of all systems elements (mechanical, electrical, 
software, etc.). : 


763 PM assess open standards mechanical 

764 PM assess open standards electrical 

765 PM assess open standards software 
The design effort shall select open standards for 766 PM select open standards based on open 
interfaces based on the criteria described in the open : systems strategy 
systems strategy (see 3.3.1). 
Selected interfaces shall be controlled by standards 767 PM use open standards Standards — 
adopted by recognized standards organizations organization based 
whenever possible. 
When these standards are not effective, de facto 768 PM use open standards market based 


standards (set by the market place) shall be used. 








6LI 


Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
4.3.4 Open PMs shali document means for assuring conformance to 769 PM plan open standards conformance 
Systems Design open standards. 
4.3.5 Software Software shall be managed and engineered using best 770 PM ~~ use best practices for software 
Engineering processes and practices that are known to reduce cost, management 
schedule, and performance risks. 
771 PM use best practices for software 
engineering 
It is DoD policy to design and develop software systems 772 PM develop - software systems 
based on systems engineering principles (CCA ) engineering 
1.4.5.1 Operational This activity shall also include the execution of 070 PM plan operational support as appropriate operational 
Support operational support plans, to include the transition from ; support plan 
contractor to organic support, if appropriate. 
071 PM plan transition from as appropriate operational 
; . contractor to support plan 


organic support 


4.3.6 Reliability, The PM shall ensure that reliability, maintainability, and 773 PM plan reliability activities 
Maintainability and availability activities are established early in the 
Availability acquisition cycle to assure meeting operational 


requirements and reduced life cycle ownership cost. 


774 PM - plan maintainability 
activities 


775 PM plan availability activities 


O8T 


Applicable DoD 5000.2R Statements 


4.3.6 Reliability, 
Maintainability and 
Availability 


4.3.7 Environment, 
Safety, and Health 


The PM shall plan and execute reliability, maintainability, 
and availability design, manufacturing development and 
test activities such that equipment used to demonstrate 
system performance prior to production reflects the 
mature design. 


All programs, regardless of acquisition category, shall 
comply with this section and be conducted in 
accordance with applicable federal, state, interstate, 
and local environmental laws and regulations, Executive 
Orders (EQs), treaties, and agreements. 


Extracted Requirements 


No. 
776 


777 


778 


779 


480 


781 


782 


783 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 
PM 


PM 


Task 


use 


comply 


comply 


comply 


comply 


comply 


comply 


comply 


Object Modifier 
mature system for performance 
verification 


federal laws and 
regulations 


State laws and 
regulations 


interstate laws and 
regulations 


local environmental 
laws and 
regulations 


- Executive Orders 


treaties 


agreements 


Using 





[8T 


Applicable DoD 5000.2R Statements 


4.3.7 Environment, The PM shall ensure that the system can be tested, 
Safety, and Health operated, maintained, and repaired in compliance with 


4.3.7.1 National 
Environmental 
Policy Act 


environmental regulations and the requirements of this 
section. 


Environmental, safety, and health (ESH) analyses shall 
be conducted, as described below, to integrate ESH 
issues into the systems engineering process and to 
support development of the Programmatic ESH 
Evaluation (see 3.3.7). 


The PM shall comply with the National Environmental 
Policy Act (NEPA) (42 USC 4321-4370d }, implementing 
regulations (40 CFR 1500-1508 ), and executive orders 
(EO 12114 and EO 11514 ) by analyzing actions 
proposed to occur in upcoming program phases that 
may require NEPA or EO analysis 


and providing the MDA with milestones and status for 
each planned analysis. 


Extracted Requirements 


No. 
784 


785 


786 


787 


788 


789 


790 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Subject Task 


ensure 


ensure 


ensure 


ensure 


analyze 


analyze 


plan 


Object 
system testing 


system operation 


system 


maintenance 


system repair 


ESH 


all actions 


analyses 





Modifier Using 


IAW environmental 
requlations 


IAW environmental 
requlations 


IAW environmental 
requlations 


IAW environmental 
requiations 


that may require NEPA 
or EO analysis 


and update MDA 


c8I 


Applicable DoD 5000.2R Statements 


4.3.7.2 To minimize the cost and schedule risks that changing 
Environmental regulations represent, the PM shall regularly review 
Compliance environmental regulations and shall analyze the 


regulations and evaluate their impact on the program's 
cost, schedule, and performance. 


4.3.7.3 System The PM shall identify and evaluate system safety and 

Safety and Health health hazards, define risk tevels, and establish a 
program that manages the probability and severity of all 
hazards associated with development, use, and 
disposal of the system. 


~ 


All safety and heaith hazards shall be managed 
consistent with mission requirements and shall be 
cost-effective. 


Extracted Requirements 


No. 
791 


792 


793. 


794 


195 


796 


797 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
analyze 


evaluate 


identify 


evaluate 


establish 


balance 


_ ensure 


Object 


current 
environmental 
regulations 


current 
environmental 
regulations 


system safety and 
health hazards 


system safety and 
health hazards 


safety and health 
management 
program 


safety and health 
hazards 


ad 


safety and health 
management 
program 


Modifier 
repeatedly 


impact on program 
cost, schedule and 
performance 


for development, use 
and disposal 


with mission 
requirements 


is cost-effective 


Using 








Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
4.3.7.4 Hazardous The PM shall establish a hazardous material management 798 PM establish hazardous material focused on materials 
Materials program that ensures appropriate consideration is given management used 
| to eliminating and reducing the use of hazardous program 
| materials in processes and products rather than simply 
: managing pollution created (EO 12856). -. 
The selection, use, and disposal of hazardous materials 799 PM evaluate selection of to minize cost to DoD 
shall be evaluated and managed considering hazardous 
environmental, safety, and health factors so that the materials 
DoD incurs the lowest cost required to protect human 
health and the environment over the system's life cycle, 
consistent with the program’s cost, schedule, and 
_ performance goals. 
800 PM evaluate use of hazardous to minize cost to DoD 
materials 
pass 
oe) 
WW 
801 PM evaluate disposal of to minize cost to DoD 
hazardous 
materials 
802 PM manage selection of to minize cost to DoD 
hazardous 
materials 
803 PM manage use of hazardous _ to minize cost to DoD 
materials 
804 PM manage disposal of to minize cost to DoD 
hazardous 


materials 


vst 


Applicable DoD 5000.2R Statements 


4.3.7.4 Hazardous Where a hazardous material use cannot be avoided, the 


Materials 


PM shail develop and implement plans and procedures 
for identifying, minimizing use of, tracking, storing, 
handling, packaging, transporting, and disposing of such 
materials and equipment. 


Extracted Requirements 


No. 
805 


806 


807 


808 


809 


810 


814 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


plan 


plan 


plan 


plan 


plan 


plan 


plan 


Object 


identification 
procedures 


minimizing use 
procedures 


tracking 
procedures 


Storing procedures 


handling 
procedures 


packaging 
procedures 


transporting 
procedures 


Modifier 


for hazardous 
materials that must be 
used 


for hazardous 
materials that must be 
used 


for hazardous . 
materials that must be 
used 


for hazardous 
materials that must be 
used 


for hazardous 
materials that must be 
used 


for hazardous 
materials that must be 
used 


for hazardous 
materials that must be 
used 


Using 





S8I 


Applicable DoD 5000.2R Statements 


4.3.7.4 Hazardous Where a hazardous material use cannot be avoided, the 


Materials 


4.3.7.5 Pollution 
Prevention 


PM shall develop and implement plans and procedures 
for identifying, minimizing use of, tracking, storing, 
handling, packaging, transporting, and disposing of such 


' materials and equipment. 


- As new technology becomes available, the PM shall 


replace hazardous materials in the system through 
changes in the system design, manufacturing, and 
maintenance processes, where technically and 
economically practical. 


To minimize costs, the PM whenever possible shall work 
with the contractor and other PMs in identifying and 
testing mutually acceptable alternatives. 


In designing, manufacturing, testing, operating, 
maintaining, and disposing of systems, all forms of 
pollution shall be prevented or reduced at the source 
whenever feasible. 


Pollution that cannot be prevented shall be recycled in an 
environmentally safe manner. 


Pollution that cannot be prevented or recycled shall be 
treated in an environmentally safe manner. 


Disposal or other releases to the environment shall be 
employed only as a last resort and must be conducted in 
an environmentally safe manner. 


Extracted Requirements 


No. 
812 


813 


814 


815 


816 


817 


818 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
plan 


replace 


coordinate 


reduce 


recycle 


treat 


release 


Object 


disposal 
procedures 


hazardous material 


investigations of 
alternative 
materials 


pollution 


pollution 


pollution 


pollution 


Modifier 


for hazardous 
materials that must be 
used 


Using 


through design, 
manufacturing and 
maintenance 
technologies 


with contractors and 
other PMs 


at the source 


in an environmentally 
safe manner 


in an environmentally 
safe manner 


in an environmentally 
safe manner 


981 


Applicable DoD 5000.2R Statements Extracted Requirements 


No. Subject Task Object Modifier Using 
4.3.7.5 Pollution | The PM shall establish a pollution prevention program to 819 PM establish pollution prevention minimize environmental 
Prevention help minimize environmental impacts and the life cycle program impact and cost 

costs associated with environmental compliance. 

The PM shall identify the following: the impacts of the 820 PM identify impacts of system 
system on the environment, actions needed to prevent on environment 
or contro! the impacts, the types and amounts of . 

pollution that will be released to the environment, ESH 

risks associated with using new technologies, and other 

information needed to identify source reduction and 

recycling opportunities. 

821 PM identify actions needed to 
prevent/ control 
impact 

822 PM identify type and amount of 
pollution 

823 PM identify ESH risks of new 


technologies 


824 PM identify other information 


In developing work statements, specifications, and other 825 PM evaluate specs to eliminate virgin 
product descriptions, EO 12873 requires PMs to . material requirements 
eliminate the use of virgin material requirements as 

practicable, and consider use of recovered materials, 

reuse of products, life cycle cost, recyclability, use of 

environmentally preferable products, waste prevention 

(including toxicity reduction or elimination), and ultimately, 

disposal, as appropriate (see FAR 11.301 ). 








| Applicable DoD 5000.2R Statements 
No. 


4.3.7.5 Pollution In developing work statements, specifications, and other 826 PM 


Prevention product descriptions, EO 12873 requires PMs to 
eliminate the use of virgin material requirements as 
practicable, and consider use of recovered materials, 
reuse of products, life cycle cost, recyclability, use of 
environmentally preferable products, waste prevention 
(including toxicity reduction or elimination), and ultimately, 

disposal, as appropriate (see FAR 11.301 ). 


827 


828 


829 


L8I 


830 


831 


832 


PM 


-PM 


PM 


PM 


PM 


PM 


evaiuate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


evaluate 


Extracted Requirements 


Subject Task Object 


specs 


specs 


specs 


specs 


- specs 


specs 


specs 


Modifier 


to consider use of 
recovered materials 


to consider reuse of 
products 


to consider life cycle 
cost 


to consider 
recyclability 


to consider use of 
environmentally 
preferable products 


to consider use of 
waste prevention 


to consider waste 
disposal 


Using 


_ Applicable DoD 5000.2R Statements Extracted Requirements 


881 


No. Subject Task Object Modifier Using 
4.3.8 Human A comprehensive management and technical strategy 833 PM ensure requirements include human 
Systems for human systems integration shall be initiated early in performance aspects 
Integration (HSI) the acquisition process to ensure that: human 
performance; the burden the design imposes on 
manpower, personnel, and training (MPT); and safety 
and health aspects are considered throughout the 
system design and development processes. 
834 PM ensure requirements include the burden the 
design imposes on 
MPT 
835 PM ensure requirements include safety and 
health aspects 
Human factors engineering requirements shall be 836 PM ensure requirements include effective 
established to develop effective human-machine human-machine 
interfaces, and minimize or eliminate system interfaces 
characteristics that require extensive cognitive, 
physical, or sensory skills; require excessive training or 
workload for intensive tasks; or result in frequent or 
critical errors or safety/health hazards. 
837 PM ensure requirements include limiting 
cognitive, physical or 
sensory skills 
838 PM ensure requirements include limiting 
excessive training or 
workload 
839 PM ensure requirements include frequent or 


critical errors or 
hazards 








Applicable DoD 5000.2R Statements 


4.3.8 Human 
Systems 
Integration (HSI) 


681 


4.3.9 
Interoperability 


4.4 Other Design 
Considerations 


No. 
The capabilities and limitations of the operator, 840 
. maintainer, trainer, and other support personnel shall be 
identified prior to program initiation (usually Milestone }), 
and refined during the development process. 
844 
842 
843 
Human-machine interfaces shall comply with the 844 


mahdatory guidelines for all C4! systems, automated 
information systems, and weapons systems that must 
interface with C4! systems or automated information 
systems, as defined in the DoD Joint Technical 
Architecture (JTA). 


The DoD JTA is mandatory for all emerging systems and 844 
systems upgrades. 


Interoperability of C4t Systems shall be in compliance 846 
with DoDD 4630.5 , DoD! 4630.8 , and CUCSI 6212.01A . 
(CCA and PRA) 


847 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
identify 


identify 


identify 


identify 


structure 


structure 


structure 


Extracted Requirements 
Subject 


Object 
capabilities 


capabilities 


capabilities 


capabilities 


interfaces 


interfaces 


C4l interfaces 


Modifier 
of the operator 


of the trainer 
of the maintainer 


of the other support 
personnel 


IAW JTA 


IAW JTA 


IAW DODD 4630.5, 
DOD! 4630.8, CUCSI 
6212.01A 


Using 


061 


Applicable DoD 5000.2R Statements Extracted Requirements 


| No. Subject Task Object Modifier Using 
4.4.1 Survivability System (to include the crew) survivability from all ‘ 848 PM assess system from all threats 
threats found in the various levels of conflict shall be 
considered and fully assessed as early as possible in 
the program, usually during Phase |. 
4.4.2 Work A program work breakdown structure (WBS) shalt be 849 PM use WBS for program planning 
Breakdown established that provides a framework for program and 
Structure . technical planning, cost estimating, resource allocations, 
performance measurements, and status reporting. 
850 PM use WBS for technical planning 
851 PM use WBS for cost estimating 
852 PM use WBS — for resource 
allocations 
853 PM use WBS for performance 
measurements 
854 PM use WBS for status reporting 
Program offices shall tailor a program WBS foreach . 855 PM tailor WBS using MIL-HDBK-881 
program using the guidance in MIL-HDBK-881, 
4.4.3 Preference shall be given to specifications and 856 PM use specs from Defense 
Standardization standards developed under the Defense Standardization Standardization 


Documentation Program. | Program 
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Applicable DoD 5000.2R Statements 


4.4.4 Metric 
System 


4.4.5 Program 
Protection 


4.4.6 Information 
Assurance 


The metric system of measurement shall be used for all 
elements of defense systems requiring new design, 

unless waived by the MDA as not in the best interest of 
the government (15 USC 205a-205k , and EO 12770 ). 


Acquisition programs shall identify elements of the 
program, classified or unclassified, that require 
protection to prevent unauthorized disclosure or 
inadvertent transfer of critical program technology or 
information. : 


Program protection planning shall begin early in the 
acquisition life cycle and be updated as required. 


The planning process shall incorporate risk management 
and threat-based countermeasures to provide 
cost-effective protection. 


Information systems shall be managed and engineered 
using best processes and practices that are known to 
reduce security risks, including the risks to timely 
accreditation. 


Extracted Requirements 


No. 
857 


858 


859 


860 


861 


‘862 


863 


Subject 


PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 


use 


identify 


plan 


plan 


plan 


plan 


plan 


Object 
metric system 


sensitive program 
elements 


program protection 


program protection 


program protection 


information 
systems 


information 
systems 


Modifier Using 


to prevent inadvertent 
transfer of technology 


to include risk 
management 


to include 
threat-based 
countermeasures 


to reduce security 
risks 


to reduce risk to timely 
accreditation 


cél 


Applicable DoD 5000.2R Statements 


4.4.6 information 
Assurance 


Information assurance requirements shall be included as 
part of program and systems design activities to ensure 
availability, integrity, authentication, confidentiality, and 
non-repudiation of critical program technology and 

~ information. 


All AlSs shall meet security requirements in accordance 
with DoDD 5200.28 and be accredited by the 
Designated Approving Authority prior to processing 
classified or sensitive unclassified data. 


Extracted Requirements 


No. 
864 


865 


866 


867 


868 


869 


870 


Subject 
PM 


PM 


PM 


PM 


PM 


PM 


PM 


Task 
develop 


develop 


develop 


develop 


develop 


develop 


develop 


Object 
requirements 


requirements 


requirements 


requirements 


requirements 


requirements 


AIS 


Modifier 


to include information 
assurance 
requirements 


to include availability 
of critical program 
tech and info 


to include integrity of 
critical program tech 
and info 


to include 
authentication of 
Critical program tech 
and info 


to include 
confidentiality of 
critical program tech 
and info 


to include 
non-repudiation of 
critical program tech 


IAW DODD 5200.28 


Using 





col 


Applicable DoD 5000.2R Statements 


4.4.6 Information 
Assurance 


4.4.7 
Electromagnetic 
Environmental 
Effects (E3) and 
Spectrum 
Management 


All AlSs shall meet security requirements in accordance 
with DoDD 5200.28 and be accredited by the 
Designated Approving Authority prior to processing 
classified or sensitive unclassified data. 


All electric or electronic systems shal! be designed to be 
mutually compatible with other electric or electronic 
equipment within their expected operational environment. 


Systems and equipment that emit or receive hertzian 
waves shall comply with OMB Circular A-11 to 
determine spectrum supportability prior to initiating cost 
estimates for development or procurement. 


All DoD components shall obtain spectrum utilization 
guidance from the Military Communications-Electronics 
Board (MCEB) in accordance with DoDD 4650.1 . 


Systems and equipment shall comply with applicable 
national and international spectrum management policies 
and regulations. 


Requirements for foreign spectrum support shall be 
forwarded to the MCEB for coordination with host 
nations where deployment of the system or equipment is 
planned. — 


Extracted Requirements 


No. 
871 


872 


873 


874 


875 


876 


PM 


PM 


PM 


PM 


PM 


PM 


Subject Task 


accredit 


develop 


determine 


obtain 


comply 


forward 


Object 
AIS 


requirements 


RF spectrum 
supportability 


RF spectrum 
guidance 


RF spectrum 
policies and 
regulations 


RF spectrum 
requirements 


Modifier Using 


using Designated 
Approving Authority 


for mutual compatibility 
of electric and 
electronic equip 


[AW OMB Circular 
A-11 


from Military 
Communications-Electr 
onics Board (MCEB) 
[AW DODD 4650.1 


national and 
international 


to MCEB for foreign 
coordination 


pol 


Applicable DoD 5000.2R Statements ss Extracted Requirements 


No. Subject Task Object Modifier Using 
4.4.8 Unplanned All munitions/weapons shall be designed to withstand 877 PM develop requirements for unplanned stimuli 
Stimuli unplanned stimuli and use materials consistent with 
safety and interoperability requirements. 
878. PM use matierials consistent with safety 


requirements 


879 PM use matierials consistent with 
interoperability 
requirements 


Requirements shall be determined during the 880 PM determine requirements requirements 
requirements validation process and shall be updated as validation 
necessary throughout the acquisition cycie for all process 
acquisition programs. 
Interoperability shall be validated per CJCS! 3170.01 , to 881 PM validate interoperability IAW CJCSI 3170.01 
include insensitive munition policies. 
882 PM validate insensitive munition IAW CJCSI 3170.01 
policy adherence 
4.4.9 Value Value Engineering (VE) shail be applied to projects and 883 PM evaluate design [AW OMB Circular Value 
Engineering programs as required by OMB Circular A-131 . A-131 Engineering 
The PM shall consider an incentive approach and/or a 884 PM consider incentives / IAW FAR 48 and contract 
mandatory approach as described in the FAR 48 and mandatory Value DFARS 248 


the DFARS 248 , Engineering 








cél 


Applicable DoD 5000.2R Statements 


4.4.10 Vertical 
Integration 


6.2.1 Acquisition 
Program Baseline 
(APB) Reporting 


Where the system design is necessarily restrictive, PMs 
shall identify and evaluate the potential for vertical 
integration and its possible effects on the program (see 
3.3.2.4), 


Program Managers (PMs) shall maintain a current 
estimate of the program actually being executed and 
shall report the current estimate of each APB parameter 


periodically, as requested, to the MDA. 


Extracted Requirements 


No. Subject 
885 PM 


886 PM 


887 PM 


888 PM 


Task 
identify 


evaluate 


maintain 


report 


Object 


vertical integration 
potential 


vertical integration 
potential 


APB 


APB 


Modifier Using 


effects on the 


current with program 
execution 


as required 
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